If ebuild uses autotools to build clang, then it requires a full llvm build. But if ebuild uses CMake, it can build clang with an external existing llvm, by specifying "-DCLANG_PATH_TO_LLVM_BUILD=/usr/ -DCLANG_PATH_TO_LLVM_SOURCE=${WORKDIR}/llvm" (the cmake way also need llvm source tree but won't build llvm again). I have llvm-9999.ebuild, clang-9999.ebuild, and lldb-9999.ebuild written in cmake way in my local overlay: https://github.com/ustcscgy/local-overlay/tree/master/sys-devel The advantages are modularity: 1. Build clang with an existing llvm, build lldb with an existing llvm and clang and so on. The compile time is reduced. 2. By using CMake, it's easy to add an ebuild for lldb, and compiling lldb will be very quick. This also solves bug #464354. 3. And build with CMake will install /usr/share/llvm/cmake/, which is required by some projects. The disadvantages are: LLVM family's CMake build system and autotools build system are not exactly equal: it seems that "ocaml" and "udis86" USE flags have no correspondings in cmake variables. Some notes on my llvm/clang/lldb ebuils using CMake: 1. I do not change much in src_prepare. 2. I build shared libraries. 3. I do not test python bindings yet. 4. Becaure lldb will not always build successfully every time, I have "ESVN_REVISION=187103" in "llvm.eclass". 5. It seems that lldb's python binding fails on linux and it's impossible to disable it, I have to change CMakeLists.txt in src_configure. That's my advice, welcome to discuss about it. Reproducible: Always
Please search the Bugzilla first. We've been working on using CMake for some time and there are still too many issues to get that into real testing. *** This bug has been marked as a duplicate of bug 456322 ***
