1, can you add an example of the difference between a dependency graph and a call-based dependency graph to the readme. I had to read the paper to find out what you were talking about.
2, I am a maintainer of cargos dependency resolution code. If emulating that algorithm is part of this project, I would be willing to help. Ping me on github or discord.
That would be extremely helpful to us, I will ping you when we will revisit/rework on the resolution algorithm, many thanks for reaching out!
/ do you make that generate?
@Eh2406 We basically generate the dependency tree using cargo (since we need to compile the package anyway). To ensure consistent dependency resolution, we configured cargo to point to a local non-updatable
crates.io-index repo (e.g basically clone a local copy of the index, remove remote fetch and then edit the local cargo installation (.cargo/cargo) to read it registry = "file:///data/prazi/crates.io-index")
@jhejderup how did you manage native dependencies?
To ensure consistent dependency resolution, we configured cargo to point to a local non-updatable crates.io-index repo
by the way, you can pass the -Zno-index-update flag to cargo to get the same behavior (it requires nightly)
On the LLVM call graph, we can identify C calls, but currently we don't handle it so it is not shown in the final Präzi graph
@pietroalbini ah very nice, wasn't aware of it, thanks :)
basically we also have the same native deps problem in crater/docs.rs, so that's a docker image with most* of the dependencies needed to build rust crates
it was created by the docs.rs developer (adding new packages every time people complained their crate wasn't in the site), and crater is going to use it soon
and also, you should probably look into https://github.com/rust-ops/crates-build-env :)
wow, fantastic, we will for sure this next time when we build crates.io
oh, yeah, I have another question
how do you cache dependencies between builds?
unfortunately sccache doesn't really like multiple builds on the same cache directory, so we can't use it for crater
the (horrible) solution we have right now is to just build everything inside a big target directory (one for each thread)
the "only" downside of that solution is like the 4tb disk usage for each run
if you have any question about how we do things in crater, I'm in the crater channel on the rust discord ;)
thanks a lot, I think we have a lot to learn from the crater project
(arrgg, these quotes :) )
bye o/
