Respect the newly-introduced LLVM_RUNTIMES_LIBDIR_SUFFIX variable that
can be used to override the libdir used to hold LLVM runtimes. Install
clang runtimes (headers & compiler-rt) there, and use it when looking
Looking more closely at this, there is a problem that I see.
The clang runtime directory only supports building compiler-rt, and is going to be replaced by the llvm runtimes directory in the (hopefully near) future.
Maybe a better way to go is to define RUNTIMES_LIBDIR_SUFFIX in LLVM and connect that into both the clang runtime and llvm runtimes directories.
I don't get it.
There is nothing "RUNTIMES" about it. And this variable is actually used to produce real libraries: libclang, etc.
It's just the LIBDIR_SUFFIX. That's it. The reason it is called CLANG_LIBDIR_SUFFIX and set from LLVM_LIBDIR_SUFFIX is to support using the CMake build of Clang in a standalone mode where there *isn't* a LLVM_LIBDIR_SUFFIX and instead the CLANG_LIBDIR_SUFFIX needs to be set directly.
So I'm really not understanding what benefit this change is bringing.
And the other comment in the CMake file that the CLANG_LIBDIR_SUFFIX must exactly match whatever LLVM_LIBDIR_SUFFIX is remains, AFAICT, 100% correct.
That is 100% incorrect. LLVM_LIBDIR_SUFFIX is used almost everywhere, mostly because it goes implicitly through LLVM's CMake macros. CLANG_LIBDIR_SUFFIX is truly only used to set the paths in the sources.
This really doesn't solve the problems we have. We don't want to build and install two almost-identical copies of compiler-rt and clang headers, when we can just build one and make clang use it.
However, as I said before, I don't really think that this approach makes sense. I don't think we should be building Clang to re-use parts of some other Clang installation. I understand that is exactly what you want to do, but I disagree that it is a good idea. I think it is brittle and failure prone. I suggested ways you could make it work for your use cases however, but I don't think changing the CMake in this way is valid.
Very well. I'll look into (ab)using the existing options to achieve the same result. Having stand-alone build systems, this should become easier these days, at least until some major change in runtime handling occurs.