On some platforms C++ headers are packaged with the compiler not the sysroot. If you don't copy C++ headers into the build include directory during configuraiton of the outer build the C++ check during the runtime configuration may get inaccurate results.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
llvm/runtimes/CMakeLists.txt | ||
---|---|---|
9 ↗ | (On Diff #200336) | Super nit: I always either leave off the ${} or enclose it in quotes inside if to avoid potentially running afoul of CMake's weird expansion rules for if. It's probably unnecessary most of the time, bit it's easy enough to do. |
43 ↗ | (On Diff #200336) | Typo: plae |
46 ↗ | (On Diff #200336) | Any reason to prefer this to either cmake -E copy_directory or file(COPY)? |
llvm/runtimes/CMakeLists.txt | ||
---|---|---|
44 ↗ | (On Diff #200336) | This is true for many other platforms, e.g. in our toolchain build it's the case as well. Can we do this unconditionally? |
46 ↗ | (On Diff #200336) | Even better, could we factor out the logic for copying headers in https://github.com/llvm/llvm-project/blob/master/libcxx/include/CMakeLists.txt#L218 to a separate .cmake module (except for the generated __config part that can be only done after we've finished configuration) and then reuse it here? |
llvm/runtimes/CMakeLists.txt | ||
---|---|---|
46 ↗ | (On Diff #200336) | I was using ditto because the code was Darwin-only and ditto has been on Darwin for every version of Darwin we support LLVM with, and ditto is way faster than cmake -E ... If we want this generalized then it should be done with cmake -E ... I'll take a stab at that shortly. |
llvm/runtimes/CMakeLists.txt | ||
---|---|---|
213 ↗ | (On Diff #200345) | Can you add a TODO to migrate to file(COPY when we switch to CMake >= 3.7? That avoids the custom function. |
I just came up with a different and slightly crazier approach to this. I'm going to test it out and will upload a new version of this patch shortly.
The only thing that Im worried about is cross-compilation accidentally picking up the libc++ headers that are built here (e.g. building on Linux for Linux with the host libc++ headers and building libc++ as a runtime). The rest looks pretty much a substitution and addition of runtime-libcxx-headers target to the runtimes build which is fine.
I dont see any problems with this change. But I'm not sure I have any interesting insight either.
libcxx/include/CMakeLists.txt | ||
---|---|---|
215 ↗ | (On Diff #200372) | Typo: should be configuration |
I think that this makes sense - the one case that I had in mind is pretty convoluted and if it breaks, we can fix it then.
Hello. I'm reasonably sure this broke build for me:
LLVM_ENABLE_PROJECTS=clang;clang-tools-extra;compiler-rt;libcxx;libcxxabi;lld;openmp
BUILD_SHARED_LIBS=ON
CMake Error at /build/libcxx/include/CMakeLists.txt:278 (add_custom_target): add_custom_target cannot create target "install-libcxx-headers" because another target with the same name already exists. The existing target is a custom target created in source directory "/build/libcxx/include". See documentation for policy CMP0002 for more details. CMake Error at /build/libcxx/include/CMakeLists.txt:279 (add_custom_target): add_custom_target cannot create target "install-libcxx-headers-stripped" because another target with the same name already exists. The existing target is a custom target created in source directory "/build/libcxx/include". See documentation for policy CMP0002 for more details.
Is this expected? Do i need to purge the build dir? If not, can this please be reverted in the mean time?