Compile times and Project organisation


#1

We have a crate which is undergoing a lot of changes right now. That crate has mod a, mod b, mod c and mod d - 4 base modules (in lib.rs) which are pretty big internally. mod b depends on facilities in mod a, mod c on mod b and mod a and finally mod d on mod a, b and c. Ideally we could have separated them into crates but that requires each of the 4 to have versions individually, do a version publish to crates.io and track them in others etc. We do not want this hassle for just now at-least. However the build times for the entire crate has become enormous (crate + tests take > 25 min to compile from scratch on Linux and > 30 on OSX). So any modification anywhere becomes a long wait.

It would be most ideal if the mods could somehow be compiled into rlibs (or equivalent) so that changes in mod d for instance does not recompile the whole thing and simply links to others. On searching workspace seems to be exactly what i need where each of mod a,b,c can be separate crates and mod d can be the super-crate accumulating others via workspace. Also all crates refer to each other via relative paths in their Cargo.toml.

However the problem is that each of them also require version to be mentioned in their Cargo.toml. Can we not have version only for the main/outermost Cargo.toml which creates the workspace while the ones inside don’t ? That way the entire stuff will be seen as one package and be published to crates.io and downloading and uploading will do so for all the sub-crates too.

So something like:

toplevel/Cargo.toml:

[package]
version = "0.1.0"

[workspace]
members = ["proj0", "proj1"]

[dependencies]
proj0 = { path = "proj0" }
proj1 = { path = "proj1" }

toplevel/proj1/Cargo.toml:

[package]
# no version information here

[dependencies]
proj0 = { path = "../proj0" }

toplevel/proj0/Cargo.toml:

[package]
# no version information here

So we publish only as toplevel - version 0.1.0 to crates.io and the whole stuff along with all the sub-crates moves together.


#2

Have you tried the incremental recompilation support in nightly?


#3

Incremental with nightly did make a huggge diff. It’s reduced from ~700 secs to ~40 secs in release optimised builds. Thanks - very eagerly waiting for this now as being the default.


#4

As far as I know, incremental compilation doesn’t allow for LTO. So for your real release build you should probably compile without incremental comp (for now). For debug/develop builds incremental compilation is fine.


Compilation issues in a multi-crate project