Thank you for the proposal! I’m definitely biased given that this is how we’ve been already building runtimes with llvm/runtimes, but I really think that this is the right direction.
I have a few suggestions:
The (toolchain) runtimes build already does much of what you’ve described. Specifically, https://github.com/llvm/llvm-project/blob/48e4b0f/llvm/runtimes/CMakeLists.txt behaves differently based on how it’s used.
-
When included from the LLVM build, it configures the subbuilds of runtimes for individual targets, this is handled by https://github.com/llvm/llvm-project/blob/48e4b0f/llvm/runtimes/CMakeLists.txt#L222-L651
-
When invoked from the subbuild, it drives the build for selected runtimes (currently libunwind, libc++abi, libc++ and compiler-rt), this is handled by https://github.com/llvm/llvm-project/blob/48e4b0f/llvm/runtimes/CMakeLists.txt#L54-L220
#2 is similar to what you’ve described in your proposal as step (and is similar to https://github.com/llvm/llvm-project/blob/48e4b0f/libcxx/utils/ci/runtimes/CMakeLists.txt) except that we use -DLLVM_ENABLE_RUNTIMES rather than -DLLVM_ENABLE_PROJECTS.
What I’d propose is splitting up https://github.com/llvm/llvm-project/blob/48e4b0f/llvm/runtimes/CMakeLists.txt into two. We’ll leave https://github.com/llvm/llvm-project/blob/48e4b0f/llvm/runtimes/CMakeLists.txt#L222-L651 in place and move https://github.com/llvm/llvm-project/blob/48e4b0f/llvm/runtimes/CMakeLists.txt#L54-L220 to https://github.com/llvm/llvm-project/blob/master/runtimes/CMakeLists.txt. This provides a direct transition path for the existing users of the (toolchain) runtimes build. We could then start improving the runtimes build as needed, turning it into the unified standalone build as you’ve suggested.
One potential improvement I’d really like to see is deduplicating the CMake modules across runtimes. An open question is whether the shared CMake logic should live in https://github.com/llvm/llvm-project/blob/master/cmake/Modules or https://github.com/llvm/llvm-project/blob/master/runtimes/cmake/Modules.
Currently, we have a special handling for compiler-rt builtins (and soon also crtbegin/crtend) because those need to be built before running any CMake checks (this will also likely apply to libc in the future). I think that unnecessarily complicates the build. Instead, I’d prefer to set CMAKE_TRY_COMPILE_TARGET_TYPE to STATIC_LIBRARY for the unified standalone build and then just build all runtimes in this build. That would allow replacing some of the complicated logic that’s duplicated in multiple runtimes (for example https://github.com/llvm/llvm-project/blob/48e4b0f/libcxx/cmake/Modules/HandleCompilerRT.cmake) with direct dependencies.
In terms of timing, I think it’d be ideal if we could prepare everything in the next few months and ask users to start migrating to the new unified standalone build. We could mark the current standalone and monorepo builds as deprecated immediately after the LLVM 12 branch point, and remove them some time later so the unified standalone build is the only supported way to build runtimes in LLVM 13. Does that sound like a reasonable timeframe?