Cargo.toml change cause a whole world build

I have noticed that when I added a new crate to Cargo.toml , the whole cargo got built, in my particular situation I am using ndarray with OpenBLAS support, adding a crate would require the BLAS being re-compiled from C++ source code and it is indeed a huge pain on my own laptop. Is there any relieve on this issue?

In Cargo the unit of compilation is the crate. So if a particular dependency takes a long time to recompile, you may want to split it into another crate, and arrange which crates depend on that crate in such a way that the crate that takes a long time does not need to be recompiled very often.

The best way to do this will depend on the details of your project, in particular which parts change frequently. One way to aim for which has worked for me in the past is to end up with a small root crate that contains either main if you are making a bin or the entry points to the library otherwise. This root just contains plumbing, so it doesn’t need to change often, and is not large. Then the dependency that takes a long time to compile and any code that unavoidably involves that dependency lives in a separate crate that has no other dependencies, if you can help it, and is only depended upon by the root crate. Then put the rest of the code in crate(s) that the root crate depends on and which again, do not depend on the crate that takes a long time to compile. You will likely end up needing a crate that contains data types that both the crate that takes a long time to compile and the other crate(s) also need. Try to avoid changing this crate too much since that will require a more or less full recompile.

Depending upon your use case, you can also explore changing the LTO settings to trade-off runtime optimization versus compile time.

1 Like

  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
  β”‚                                      β”‚  β”‚   Shared     β”‚
  β”‚                                      β”‚  β””β”€β”€β”€β–²β”€β”€β”€β–²β”€β”€β”€β–²β”€β”€β”˜
  β”‚                                      β”‚      β”‚   β”‚   β”‚
  β”‚      The rest of the code            β”œβ”€β”€β”€β”€β”€β”€β”˜   β”‚   β”‚
  β”‚                                      β”‚          β”‚   β”‚
  β”‚                                      β”‚          β”‚   β”‚     β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
  β”‚                                      β”‚          β”‚   └──────                 β”‚
  β”‚                                      β”‚          β”‚         β”‚ Slow to compile β”‚
  β”‚                                      ◄───────┐  β”‚ β”Œβ”€β”€β”€β”€β”€β”€β”€β–Ί part of the codeβ”‚
  β”‚                                      β”‚       β”‚  β”‚ β”‚       β”‚                 β”‚
  β”‚                                      β”‚       β”‚  β”‚ β”‚       β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
  β”‚                                      β”‚  β”Œβ”€β”€β”€β”€β”΄β”€β”€β”΄β”€β”΄β”€β”€β”€β”€β”€β”
  β”‚                                      β”‚  β”‚     Main      β”‚
  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Because dependency relationships fundamentally form a Directed Acyclic Graph, I always find myself picturing that graph when thinking about them. Maybe this diagram that resembles the picture I had in my head would be useful for understanding the idea at a glance. Arrows from a to b in this case mean "a depends on b".

1 Like