Building compiler-rt + libcxx doesn't use in-tree libcxx headers

[glandium]

STR, on a mac with MacOSX11.1.sdk (any SDK < 11.3 should do, alternatively, remove the usr/include/c++ directory from the SDK):

$ cmake -DLLVM_ENABLE_PROJECTS=clang -DCMAKE_BUILD_TYPE_RELEASE -B obj llvm
$ make -C obj
$ cmake -DLLVM_ENABLE_RUNTIMES="compiler-rt;libcxx;libcxxabi" -DCMAKE_C_COMPILER=$PWD/obj/bin/clang -DLLVM_CONFIG=$PWD/obj/bin/llvm-config -DCOMPILER_RT_ENABLE_IOS=OFF -DCOMPILER_RT_ENABLE_WATCHOS=OFF -DCOMPILER_RT_ENABLE_TVOS=OFF -B obj2 runtimes
$ make -C obj2

The last command fails with e.g.:

In file included from (...)/compiler-rt/lib/orc/debug.cpp:13:
(...)/compiler-rt/lib/orc/debug.h:16:10: fatal error: 'atomic' file not found
#include <atomic>
         ^~~~~~~~
1 error generated.

Failures happen in all C++ code in compiler-rt because SDKs before MacOSX11.3.sdk didn't include the C++ headers, and for some reason the -I${LIBCXX_GENERATED_INCLUDE_DIR} doesn't make it to the flags for those files, while it makes it for C++ code for e.g. libcxxabi. Interestingly, the dependencies are set correctly for the C++ headers to be generated before the C++ code is compiled, only the -I flag is missing. Also interestingly, things work properly when doing it all with one cmake invocation using both LLVM_ENABLE_PROJECTS and LLVM_ENABLE_RUNTIMES.

-DCMAKE_CXX_FLAGS=-I$PWD/obj2/include/c++/v1 works around the problem.

[glandium]

> -DCMAKE_CXX_FLAGS=-I$PWD/obj2/include/c++/v1 works around the problem.

Interestingly, adding this on other platforms breaks the build because of missing __config_site.

Scrap that, that was coming from -DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON

[i3roly]

can confirm this issue on 10.14 trying to build compiler-rt standalone using

cmake . -B build -DCMAKE_C_COMPILER=/Users/Gagan/.mozbuild/clang/bin/clang -DCMAKE_CXX_COMPILER=/Users/Gagan/.mozbuild/clang/bin/clang+