[llvm] [CI] Switch to a single runtimes build (PR #131913)

[Aiden Grossman via llvm-commits]

boomanaiden154 wrote:

> Good to know, but it seems that we run things twice: once via buildkite, once via github. Is that accurate?

Yes. But we've just temporarily doubled the total capacity that we have in GCP, so there is no regression in performance. The plan eventually is to try and roll the quota from the old system into the new system though.

> This was discussed during Clang WG meeting yesterday. There were no objections to cut C++03 configuration, but C++26 and Clang Modules configurations were deemed important. Can we start with removing C++03?

That sounds reasonable enough to me. I can modify this patch to do that.

> Yes, I'm aware that specifying libcxx and other runtimes in LLVM_ENABLE_PROJECT is deprecated, and that makes sense. However, the part I'm not following is how this patch help with any of that. CMake invocations that you remove don't use LLVM_ENABLE_PROJECTS at all, so they are not going to be affected even after this deprecated feature will be removed.

The current system builds most other projects using the projects build. For example, libc is currently built using `LLVM_ENABLE_PROJECTS`, but that configuration will eventually get deprecated. Switching to a single runtimes build, or at least understanding what is important to test will make that migration simpler.

> I've seen libc++ C++26 build catching errors last year, when I was working on this part of pre-commit CI. This is of course an anecdotal evidence, but I'd be surprised if anyone has more than that for any project in the monorepo. Above Matheus mentioned that Clang Modules build, too, catches issues for him, and given how little contributors we have in this area, testing this part of Clang becomes even more important to prevent bitrot. Also, it seems that lately modules-related bug reports are files almost on a daily basis: https://github.com/llvm/llvm-project/issues?q=is%3Aissue%20state%3Aopen%20label%3Aclang%3Amodules

Yeah, I don't think there is hard data on these sorts of things, and they're hard to track unless people go through and manually review all the failures which is a huge time stink. Anecdotes are perfectly fine. This is good to know.

> Looking at the code above, I don't understand why libc++ and friends are built for MLIR, LLVM, and Flang. If that's the case, then I agree that it doesn't bring a significant amount of additional coverage, and can be disabled.

I reverted the patch that was doing that as it seemed to also be helping to push things over the edge, at least for MLIR and Flang. Changing LLVM will still cause these to be built. When I get to reworking the dependency system, I will make sure to adjust the runtimes builds to only test these configurations when testing clang, which I think should give us the best balance.

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