I have a workspace which contains several binary crates, and presently I have a CI script which builds each crate individually and does stuff with the resulting binary. However, to speed things up, I wanted to build all of my crates in parallel.
Right now, my CI script looks like this:
cargo build --release -p crate1 --bin crate1bin
# Test crate1bin
cargo build --release -p crate2 --bin crate2bin
# Test crate2bin
cargo build --release -p crate3 --bin crate3bin
# Test crate3bin
I thought I would be able to make it faster by building all the crates at the start, so they can be built in parallel, and then test them, so I changed my script to look like this:
cargo build --release -p crate1 --bin crate1bin -p crate2 --bin crate2bin -p crate3 --bin crate3bin
cargo build --release -p crate1 --bin crate1bin
# Test crate1bin
cargo build --release -p crate2 --bin crate2bin
# Test crate2bin
cargo build --release -p crate3 --bin crate3bin
# Test crate3bin
By my understand of how rust reuses crates, I thought the first call to cargo build would build everything, and then the next three would recognize that it has been built and not need to build anything. However, when I do this, it still has to rebuild crates 1 and 2, along with their dependencies (though crate3 and its dependencies can be reused). If I remove the -p crate3 --bin crate3bin from the first line, then crates 1 and 2 don't need to be rebuilt, as I expected.
Running with verbose output, I looked at the calls to rustc from each case, and the only difference I saw seems to be with two of the codegen options, -C metadata and -C extra-filename, which appear to be some sort of hash, which seems to be consistent for each crate between runs if I only include crate1 and crate2, but changes to a different value if I include crate3. It looks like these two options cause rustc to maintain a separate set of build artifacts for when crate3 is included vs. when it isn't, suffixed by the different hashes.
Is this understanding of cargo build's incremental compilation and its relation to those codegen arguments correct? I haven't found any documentation online confirming this behavior (though maybe I just haven't found the right docs). And, if this is true, is there anything I can do to figure out why including crate3 causes this to happen, or to fix it so it doesn't keep two separate sets of build artifacts that it can't mix?