This switches from a macro that simply wraps genrules to a proper Starlark rule that runs first compile and then link actions.
Most interestingly, this uses the rule structure to allow using the Carbon toolchain built either in the target config or the exec config. While the exec config is more principled and even necessary in a cross-compile situaiton, it is dramatically less efficient when developing Carbon as all the binaries and tests outside of our examples will be built with the target config. This triggers a complete second build of the toolchain in the exec config for examples before this PR.
It is tempting to try to keep the exec config but make it not cause redundant actions, but the way Bazel sets up exec and target config makes it essentially impossible to share their artifacts. There used to be a hack in Bazel itself to force sharing but it was removed due to it violating the principled design. Instead, these rules are explicit about their intent to use the target config, much like a test would be.
I have rigged up a flag that is carefully threaded through a wrapper macro with selects to allow easily switching to the exec configuration in case it is desired or needed. But the the .bazelrc sets the default to the target config. The BUILD file default is the principled exec in case these rules are used by importing into some other Bazel workspace where we might only need the exec config.
The net outcome of this is shaving over 2500 actions off of a clean rebuild such as is triggered by a version bump to LLVM, including some of the very slow and expensive compiles of LLVM and Clang themselves. These would only be triggered if you built the examples so this may mostly impact our CI latency.
This switches from a macro that simply wraps genrules to a proper Starlark rule that runs first compile and then link actions.
Most interestingly, this uses the rule structure to allow using the Carbon toolchain built either in the target config or the exec config. While the exec config is more principled and even necessary in a cross-compile situaiton, it is dramatically less efficient when developing Carbon as all the binaries and tests outside of our examples will be built with the target config. This triggers a complete second build of the toolchain in the exec config for examples before this PR.
It is tempting to try to keep the exec config but make it not cause redundant actions, but the way Bazel sets up exec and target config makes it essentially impossible to share their artifacts. There used to be a hack in Bazel itself to force sharing but it was removed due to it violating the principled design. Instead, these rules are explicit about their intent to use the target config, much like a test would be.
I have rigged up a flag that is carefully threaded through a wrapper macro with
selects to allow easily switching to the exec configuration in case it is desired or needed. But the the.bazelrcsets the default to the target config. TheBUILDfile default is the principledexecin case these rules are used by importing into some other Bazel workspace where we might only need the exec config.The net outcome of this is shaving over 2500 actions off of a clean rebuild such as is triggered by a version bump to LLVM, including some of the very slow and expensive compiles of LLVM and Clang themselves. These would only be triggered if you built the examples so this may mostly impact our CI latency.