Building large projects takes quite long, bc of the amount of dependencies. So I thought maybe the building speed could be improved through dylibs. If everything would be a dylib that would improve the build time wouldn’t it? Wouldnt this make sense for debug build?
This would only improve build time if those dylibs already existed on the system to link against; if cargo has to build the dylibs this isn't any faster.
So, to the extent this would save build time, caching built copies of crates would likely save the same build time, and be substantially easier to implement. (And work on that is already in progress.)
3 Likes
Since link time contributes to overall build time, this isn't strictly true. With a large dependency graph, dynamic linking does enough less work than static linking to make a noticeable difference.
Especially if you set up a deliberate narrow waist between major subcomponents like Amos did, but even if you don't it helps a lot, since basically the entire dependency graph needs to be linked every build.
FWIW I've been using a system wide shared $CARGO_TARGET_DIR for years now and only very occasionally (and always when juggling toolchains) run into any issues.
1 Like
Bevy has specific support for enabling dynamic linking for faster development (using an intermediate crate with crate-type = ["dylib"]) so that rebuilds don't need to relink the entire game engine.
It would be nice if things like this could be done more easily, as configuration by the developer rather than complicating the dependency graph.
1 Like
Something similar was recently discussed at Blazing Fast Unlinking
See also crates.io: Rust Package Registry.