[PATCH] D132480: [llvm] Remove libcxx, libcxxabi and libunwind from supported LLVM_ENABLE_PROJECTS

Wed Sep 21 05:36:19 PDT 2022

ldionne added a comment.

In D132480#3804400 <https://reviews.llvm.org/D132480#3804400>, @ldionne wrote:

> In D132480#3804015 <https://reviews.llvm.org/D132480#3804015>, @Ericson2314 wrote:
>
>> If we try to build docs with `LLVM_ENABLE_RUNTIMES` might it try to bootstrap them, wasting effort?
>
> No, it won't.
>
> I'm still working on this, I'll update this thread tomorrow. If I don't manage to get this working tomorrow morning, I'll revert this.

I'm going deeper and deeper into the rabbit hole and as I gain more understanding of how the bootstrapping build works, this is not looking positive. Basically, my understanding is that we *have* to build Clang (and compiler-rt) before we even configure the other runtimes, because that's required for their CMake configuration to work properly. When we configure the runtimes like libcxx, CMake performs various compiler checks (like is `-fsomethingsomething` available), and that obviously requires having the compiler built already. When I think about it, it makes sense: the documentation could even technically include different content based on the compiler we're building libc++ for (although we don't do that and I think it'd be a bad idea).

This is obviously wasted effort in the context of generating only our documentation. Currently, the only way forward I can think of is to change the documentation jobs to perform two CMake invocations: first build the documentation with an invocation rooted at `llvm` and using `LLVM_ENABLE_PROJECTS=clang;lld;etc`, and then build the documentation for the runtimes with an invocation rooted at `<root>/runtimes` using `LLVM_ENABLE_RUNTIMES=libcxx;libcxxabi;etc`. I'm going to revert this change temporarily as I look at how to make these changes.

>> That was my concern when I hit this before. TBH I feel putting them under LLVM_ENABLE_PROJECTS while silly, did express well that everything can be built in parallel (modulo "regular" header dependencies like Clang -> LLVM) without bootstrapping being needed.

Yeah, I get you. That being said, there were a lot of problems with supporting that, for example the fact that `llvm/CMakeLists.txt` creates a lot of variables and selects a lot of defaults that don't make sense for the runtimes. I had documented that in some of the posts I made when we agreed to move the runtimes out of `LLVM_ENABLE_PROJECTS` a few years back.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132480/new/

https://reviews.llvm.org/D132480