Compilation firewalls in Rust

I’ve been hacking on rust-lexer recently and spend quite some time waiting for the stage1 compiler to build. Naturally, it was the perfect occasion to think about compilation firewalls for Rust.

My understanding is that, in gigantic projects, one goes out of the way to break compile-time dependencies between modules, to avoid excruciatingly slow rebuilds. In C++, this is achieved by carefully crafting header files: if you don’t change .h, you don’t have to recompile anything, only re-link (which gives raise to the pimpl). I’ve heard that at Google they do something similar for Java, by producing so-called “interface jars”: jars with only interface definitions, whose implementation is substituted at runtime using DI.

Do we have something similar for Rust already? I guess we can implement Java-style DI on top of dyn traits by hand, but it feel that this is going to be really unwieldy and limiting.

Are there any plans for language/compiler features to enable these sorts of firewalls while maintaining static dispatch, a-la C++? I guess my ideal here is that if crate’s pub API consist solely of non-generic functions, than any change not touching the API should not cause downstream dependencies to be rebuild at all. I this could work by compiler producing some-sort of “interface” file alongside the .rlib, making intermediate downstream crates to depend only on this interface files, and making only the final artifact (binary, dylib, staticlib) to depend on both interfaces and rlibs?

5 Likes

I've heard that bazel build java's jar files with two steps:

  1. Extract all public class, methods etc
  2. Build jar (in the same way as other java's build system do)

Because of (1) it is possible to continue build of other modules that depend on current one without waiting for full rebuild.

But as I understand cargo almost can do the same Implement the Cargo half of pipelined compilation (take 2) by alexcrichton · Pull Request #6883 · rust-lang/cargo · GitHub , after implementation I suppose it is possible to add some kind of caching mechanism, so crate rebuild doesn't happens if there are no changes in public interface of dependency . And that's all?

5 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.