@tstellar There’s a question of whether we should support sparse checkouts or whether we should always require full LLVM checkout that was raised on ⚙ D124315 lld: Bundle compact_unwind_encoding.h in lld to fix stand-alone builds. If we decide on the latter, that is requiring full LLVM checkout, a related question I have is whether we need to support building individual projects as standalone CMake builds?
The direction I have in mind is the following. Today it’s possible to do:
cmake ../clang && ninja clang
to build just Clang against prebuilt libLLVM.
I’d like to propose that we not only always require a full LLVM checkout, but also deprecate standalone builds of individual projects, and instead extend LLVM_ENABLE_PROJECTS.
Today, you can already do the following:
cmake ../llvm -DLLVM_ENABLE_PROJECTS=clang && ninja
but doing so also builds LLVM itself because LLVM_ENABLE_PROJECTS handling is done inside the LLVM build and thus always pull in the rest of LLVM:
I’d like to change that and instead lift the handling of LLVM_ENABLE_PROJECTS to the root, so the example above would only build Clang against the prebuilt libLLVM:
cmake .. -DLLVM_ENABLE_PROJECTS=clang && ninja
If you wanted to build Clang and LLVM together, you’d have to use:
cmake .. -DLLVM_ENABLE_PROJECTS=clang;llvm && ninja
This would let us remove the standalone build handling logic which is currently duplicated in all projects and introduces maintenance overhead.
This matches the model we use for runtimes. For example, with the following:
cmake ../runtimes -DLLVM_ENABLE_RUNTIMES=libcxx && ninja
you will only build libc++ and no other runtimes, but the common CMake configuration can be shared across all runtimes. This is the model I’d like to use for projects as well.
Would the model I described above work for your use cases?