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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
430 ms | linux > HWAddressSanitizer-x86_64.TestCases::sizes.cpp |
Event Timeline
Sorry, I'm not sufficiently familiar with LLVM's build system to review this. I work on the runtimes almost exclusively. @smeenai might be a better fit here.
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:
https://github.com/ilelann/IncludeOS/blob/master/CMakeLists.txt#L77-L130
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.