<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I like the idea! A few comments below.<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 6, 2017, at 6:28 AM, NAKAMURA Takumi <<a href="mailto:geek4civic@gmail.com" class="">geek4civic@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I am running a builder; <a href="http://bb.pgr.jp/builders/bootstrap-clang-libcxx-lld-i686-linux" class="">http://bb.pgr.jp/builders/bootstrap-clang-libcxx-lld-i686-linux</a><div class="">(Note, it's not i686 but actually x86-64 due to issues atm)</div><div class="">It is doing;</div><div class="">- Build stage1-clang with g++-4.8</div><div class="">- Build stage2-libcxx (and libcxxabi) with stage1-clang</div></div></div></blockquote><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">- Build stage2-clang with just-built in-tree libcxx (and libcxxabi) with stage1-clang</div><div class=""><br class=""></div><div class="">At the moment, its buildsteps are hacky and hairy.</div><div class="">I noticed they could be simplified and useful.</div><div class=""><br class=""></div><div class="">I propose an option like LLVM_ENABLE_INTREE_LIBCXX.</div><div class="">(Or enhance LLVM_ENABLE_LIBCXX)</div></div></div></blockquote><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Pros:</div><div class=""> Clang (and other executables) can be linked to in-tree libc++.so.</div><div class=""><br class=""></div><div class="">Cons:</div><div class=""> Let me know. </div><div class=""><br class=""></div><div class="">Prerequisites:</div><div class="">- CMAKE_CXX_COMPILER is capable to build libcxx</div><div class="">- libcxx (and libcxxabi etc.) is checked out</div></div></div></blockquote><div><br class=""></div>Seems reasonable.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">What to be tweaked:</div><div class="">1) Omit testing functionality of C++ in config-ix.cmake.</div><div class=""> Most of tests wouldn't make sense, since they are about to be built in-tree.</div><div class=""> I think just to detect compiler id, or check functionality without headers nor libraries.</div></div></div></blockquote><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">2) Use in-tree headers to build all C++ source files.</div><div class=""> Add -I (BUILD_ROOT)/projects/libcxx/include -I $(LIBCXX_ROOT)/include.</div><div class=""> Then, -stdlib=libc++ might confuse #include_next.</div><div class=""> It'd be better to add -stdlib=other_but_libc++.</div></div></div></blockquote><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">3) Link all libraries (not just LLVMSupport) and executables to libc++.</div><div class=""> It'd be easy simply to specify -L $(BUILD_ROOT)/lib.</div><div class=""> But I suggest to add libcxx for each library and executable with target_link_libraries(cxx).</div></div></div></blockquote><div><br class=""></div><div>Using target_link_libraries for this would not be correct because LLVM's CMake shouldn't ever need to know about the cxx targets.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">4) Make sure libc++ is built in advance of others.</div><div class=""> As I mentioned in (3), target_link_libraries(cxx) should do.</div><div class=""> Surprisingly, object files in libcxx, libcxxabi, and LLVMSupport can be built in parallel! (with ninja)</div></div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><div>Does this all make sense?</div><div>-Chris</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Takumi</div></div>
</div></blockquote></div><br class=""></div></body></html>