With this change, libc-hdrgen is built like a host build tool like clang and used
to build libc for the target.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/runtimes/CMakeLists.txt | ||
---|---|---|
368 | This can have potentially negative side-effects. Take for example Fuchsia's CMake cache file where on Darwin we set the generic flags which are passed to the "default" build as well as prefixed flags which are passed to target build. With this change, the generic flags will be passed to the target build and interfere with the prefixed flags. Can we avoid this change for now? |
llvm/runtimes/CMakeLists.txt | ||
---|---|---|
368 | To add some additional context, I'm planning major changes to how the "default" and target builds are set up, and after those changes, this should be possible without any negative side-effects, but that's going to take a few more weeks. |
llvm/runtimes/CMakeLists.txt | ||
---|---|---|
368 | The other option is to detect the libc specific options and pass them as CMAKE_ARGS. For now, we only need to test for LLVM_LIBC_FULL_BUILD. If that is OK, then we can avoid depending on prefixes. |
llvm/runtimes/CMakeLists.txt | ||
---|---|---|
368 | That would be my preference, at least for now. |
llvm/runtimes/CMakeLists.txt | ||
---|---|---|
368 | How does the latest diff look? |
llvm/runtimes/CMakeLists.txt | ||
---|---|---|
388–389 | Nit: this is unnecessary (uninitialized variables in CMake evaluate to empty string). | |
397–398 | This is slightly counterintuitive. I'd prefer introducing a special handling in llvm/CMakeLists.txt similarly to what we do for example for flang and mlir, see https://github.com/llvm/llvm-project/blob/830d116d776439093a16aad567cd3db2c4c3cd72/llvm/CMakeLists.txt#L143 and automatically including libc in LLVM_ENABLE_PROJECTS when libc is in LLVM_ENABLE_RUNTIMES. |
llvm/runtimes/CMakeLists.txt | ||
---|---|---|
397–398 | I left this check here as a debug aid, but have also updated llvm/CMakeLists.txt according to your suggestion. |
Remove a spurious arg which was not removed when addressing the last round of comments.
This can have potentially negative side-effects. Take for example Fuchsia's CMake cache file where on Darwin we set the generic flags which are passed to the "default" build as well as prefixed flags which are passed to target build. With this change, the generic flags will be passed to the target build and interfere with the prefixed flags. Can we avoid this change for now?