4 ms·
It looked to me like putting toolchain and bespoke tool dependencies into Bazel rules was about as manual as any other build system (e.g., next to impossible in
by kabdib 6y ago
It looked to me like putting toolchain and bespoke tool dependencies into Bazel rules was about as manual as any other build system (e.g., next to impossible in a cross-platform manner, and error-prone at best).
The correct response for a compiler upgrade or a modification to a bespoke tool that generates a product is almost certainly a full rebuild unless you have very high confidence that you've identified ALL the dependencies. I believe this is not easily discoverable (e.g., you might have a dependency on "/usr/bin/cc", but not know enough about 'cc's internals to realize that you also have to have a dependency on "/usr/local/lib/cc1-arm-bfhsh-37.so" for some specific compiler option).
I'd like to believe you, but I have scars from doing build systems and discovering all the wacky and wonderful things that tools do.
- klodolph 6y agoBazel sandboxes the build rules. If you need to discover dependencies, you can flip a switch and have all the missing dependencies be hard errors. Once you flip the switch and fix the errors, you leave it flipped on and you have confidence that you are not missing any dependencies. The entire C toolchain is normally an input to a Bazel build. You make a package (.tar.gz) containing the toolchain, put it somewhere accessible (http), and check a SHA-256 hash of the toolchain into your WORKSPACE file. When it changes, everything built with it is rebuilt. Getting complicated cross-platform toolchains working on Bazel is going to be hard, sure. But knowing whether you have hidden dependencies is not hard, because of the sandboxing.