Including lib does not seem to be required when one want, example given, to build libcxx.
Same rationale as the others LLLM_INCLUDE options: it reduces the number of targets, and makes life inside IDE easier.
|430 ms||linux > HWAddressSanitizer-x86_64.TestCases::sizes.cpp|
Script: -- : 'RUN: at line 3'; /mnt/disks/ssd0/agent/llvm-project/build/./bin/clang --driver-mode=g++ -m64 -gline-tables-only -fsanitize=hwaddress -fuse-ld=lld -mcmodel=large -mllvm -hwasan-globals -mllvm -hwasan-use-short-granules -mllvm -hwasan-instrument-landing-pads=0 -mllvm -hwasan-instrument-personality-functions /mnt/disks/ssd0/agent/llvm-project/compiler-rt/test/hwasan/TestCases/sizes.cpp -nostdlib++ -lstdc++ -o /mnt/disks/ssd0/agent/llvm-project/build/projects/compiler-rt/test/hwasan/X86_64/TestCases/Output/sizes.cpp.tmp
Oh, I looked a bit fast. I think I understand the intent here -- you're trying to make it easier to build libcxx as part of the monorepo without the rest of LLVM?
I don't think that's the right way forward, I think we need to setup a separate build root for the runtimes.
That is the intent indeed.
Starting from the "official" build instructions found here https://libcxx.llvm.org/docs/BuildingLibcxx.html, I ultimately got this CMake incantation to get a minimal libunwind+libcxxabi+libcxx static build:
And I am totally happy with it, despite the arguably long list of flags.
The additionnal LLVM_INCLUDE_LIB proposed here is only to avoid configuring and building a large set of irrelevant targets.
With my patch and LLVM_INCLUDE_LIB set to OFF, the "pollution" brought by including the main LLVM CMake file is really minimal: when I "make" my super-project I don't notice any irrelevant target.