[llvm] [Bazel] Make LLVM and Clang config headers configurable (PR #126729)

[Aaron Siddhartha Mondal via llvm-commits]

aaronmondal wrote:

> whereas with something that shells out to a script can just pass ["ENABLE_BACKTRACES=1", "HAVE_BACKTRACE=1"] and let the script take care of the difference between #cmakedefine01 and #cmakedefine in the config.h.cmake template.
> 
> By default, llvm/utils/gn/build/write_cmake_config.py is a reasonable first pick for such a script, but it doesn't need to be -- we could write a new one, or even cmake -P kinda works, if we can rely on cmake existing on the build host.

I wonder whether it's feasible to automate the generation of the `config.bzl` file and all its selects via an offline script. I'm not sure how hard it would be to do so, but I'm thinking something like a script that runs `cmake -P` on a bunch of emulators. This could then be used as a diff (or should I say *drift* :laughing:) test for the config targets to keep it perfectly in sync.

For the actual `config.bzl` the issue with a python (or cmake) script is that it would increase the closure size of these targets by quite a bit.

At the moment the entire clang build can get by without python on a remote executor with this patch: https://github.com/eomii/rules_ll/blob/main/patches/llvm-project-bundle-with-bash.diff

If we used python (or cmake) we'd have to manage additional (potentially cross-)toolchains for all the various platforms. At some point (e.g when lit tests need to run) we'll need it, but it's nice if we can shift this to as late in the build graph as possible. This way the workers that usually only act as exec platform for cc_toolchains often get by without ever fetching python.

Another nice effect of deferring toolchain requirements in the build graph is that it reduces their "hotness" in a multi-layer cache systems. The less often we need to touch a toolchain artifact, the more space remains for the real build artifacts.

https://github.com/llvm/llvm-project/pull/126729