[cfe-dev] [PROPOSAL] Add an option to build Clang with in-tree libcxx

[Chris Bieneman via cfe-dev]

I like the idea! A few comments below.

> On Jul 6, 2017, at 6:28 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote:
> 
> I am running a builder; http://bb.pgr.jp/builders/bootstrap-clang-libcxx-lld-i686-linux <http://bb.pgr.jp/builders/bootstrap-clang-libcxx-lld-i686-linux>
> (Note, it's not i686 but actually x86-64 due to issues atm)
> It is doing;
> - Build stage1-clang with g++-4.8
> - Build stage2-libcxx (and libcxxabi) with stage1-clang

Minor correction, you actually want the stage1 libcxx. If you build libcxx using LLVM's runtimes directory the stage1 libcxx will be built with the stage1 clang, which is what you want.

> - Build stage2-clang with just-built in-tree libcxx (and libcxxabi) with stage1-clang
> 
> At the moment, its buildsteps are hacky and hairy.
> I noticed they could be simplified and useful.
> 
> I propose an option like LLVM_ENABLE_INTREE_LIBCXX.
> (Or enhance LLVM_ENABLE_LIBCXX)

I like LLVM_ENABLE_INTREE_LIBCXX rather than overloading the meaning of LLVM_ENABLE_LIBCXX. If BOOTSTRAP_LLVM_ENABLE_INTREE_LIBCXX=On during a build we can make libcxx a dependency of the bootstrap build, and it will pass through LLVM_ENABLE_INTREE_LIBCXX to the next stage, which we can then interpret for using the in-tree library.

> 
> Pros:
>   Clang (and other executables) can be linked to in-tree libc++.so.
> 
> Cons:
>   Let me know.  
> 
> Prerequisites:
> - CMAKE_CXX_COMPILER is capable to build libcxx
> - libcxx (and libcxxabi etc.) is checked out

Seems reasonable.

> 
> What to be tweaked:
> 1) Omit testing functionality of C++ in config-ix.cmake.
>   Most of tests wouldn't make sense, since they are about to be built in-tree.
>   I think just to detect compiler id, or check functionality without headers nor libraries.

You don't want to change this. Instead this should rely on the stage1 libcxx being built with the stage1 clang (via the runtimes directory) so that the stage2 configuration has the library available.

> 2) Use in-tree headers to build all C++ source files.
>   Add -I (BUILD_ROOT)/projects/libcxx/include -I $(LIBCXX_ROOT)/include.
>   Then, -stdlib=libc++ might confuse #include_next.
>   It'd be better to add -stdlib=other_but_libc++.

Not sure how this works on other platforms, but we already effectively do this on Darwin because the header search path includes the compiler resource directory which is relative to the compiler's path on disk. It might be sufficient to just pile the headers into the resource directory on all platforms.

> 3) Link all libraries (not just LLVMSupport) and executables to libc++.
>   It'd be easy simply to specify -L $(BUILD_ROOT)/lib.
>   But I suggest to add libcxx for each library and executable with target_link_libraries(cxx).

Using target_link_libraries for this would not be correct because LLVM's CMake shouldn't ever need to know about the cxx targets.

> 4) Make sure libc++ is built in advance of others.
>   As I mentioned in (3), target_link_libraries(cxx) should do.
>   Surprisingly, object files in libcxx, libcxxabi, and LLVMSupport can be built in parallel! (with ninja)

We can accomplish this today if you use the LLVM runtimes directory because libcxx will be part of the stage1 build not the stage2 build.

Does this all make sense?
-Chris

> 
> Thanks,
> Takumi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170710/8cc55cac/attachment.html>