[cfe-dev] CMake Question: Do we need to support stand-alone builds?

[Douglas Gregor]

On Jun 26, 2012, at 12:01 AM, Chandler Carruth wrote:

> Hello folks,
> 
> TL;DR: When working on better/simpler CMake suport for Clang/LLVM I am often thwarted by one of the most complex parts of the Clang setup: the ability to do a "standalone" build of Clang. I would like to get rid of this feature in order to simplify and make more progress. Any objections?
> 
> 
> Most people don't even know what the "standalone" build is, so in summary it allows you to check out *just* clang and to build it against a separate checkout and build tree of LLVM. It doesn't re-use the build output tree of LLVM, or the source tree of LLVM.
> 
> Why does this exist? I'll try to summarize the points from the last time I talked to Doug about it, but honestly, I don't use this so I may mess it up. I've CC-ed Doug who is (I suspect) one of the few using it to clarify anything I miss:
> 1) It allows updating the LLVM source checkout and build tree less frequently than the Clang checkout and build tree.
> 2) It allows sharing a single LLVM checkout and build tree amongst many Clang checkouts and build trees.
> 3) ???
> 
> Certainly #1 and #2 can (in some cases) combine to improve incremental rebuild speed, but in practice I rarely benefit from them as the time is now heavily dominated by running the test suite. Thus, I see this benefit as diminishing these days, and also as offset by improved performance of CMake, especially when coupled with the bleeding edge ninja system.

3) CMake generates gigantic project files for IDEs like Visual Studio and Xcode, which causes those IDEs to behavior very poorly, with long project load times and sluggish overall performance. It's a significant productivity problem.

> 
> Now, why do I want to get rid of this? What is it preventing or getting in the way of?
> 1) Remove duplication! Massive amounts of the CMake infrastructure of LLVM are copied into Clang's CMake build in order for the latter to not depend on the former. What's worse, these copies have evolved independently and now often diverge, duplicate bugs, and sometimes give birth to their own bugs.
> 
> 2) Remove duplication! The 'lit' based test running is needlessly duplicated in Clang's CMake build. It is also incorrect, missing dependencies, and behaving differently from LLVM's. Yep. 'make check && make clang-test' does not in fact test the same thing as 'make check-all'. Scary, eh?

The duplication could be solved by installing some of LLVM's CMake macros in a place where Clang could find and re-use them. Think of it this way: we'd like to make it easy to use LLVM, or LLVM+Clang, as a library, so that other projects that use CMake can easily import the "FindLLVM" module and make use of LLVM. Clang should be able to simply do this, so that Clang is just an external tool build on the LLVM core. LLDB is another external tool that builds on the LLVM core and on Clang, and so on.

> 3) Integrate with CompilerRT: This comes out of the LLVM projects subtree, and so is inherently missing in a stand-alone build.
> 
> 4) Integrate with libc++: Same story as CompilerRT.

These might be reasonable to pull into the Clang build, since the Clang installation is not whole without them. Luckily, they're fairly small.

> 5) Integrate support for automatic bootstrapping: This will be among the most complex things to add to our CMake builds, but also one of the highest value. I'd really like to not spend time thinking about how this interacts with Clang's standalone cmake bits, but I have to as long as its there.


I don't see how a stand-alone build of Clang gets in the way of bootstrapping. Bootstrapping is going to be very odd in CMake regardless.

Overall, I look at "standalone Clang builds" as simply "Clang using LLVM as the library like it's intended to be." That's an important use case in and of itself, and Clang is simply the LLVM-based tool that's most near and dear to us. That doesn't mean it's build should be intertwined with LLVM's build.

	- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120626/9fd6af8c/attachment.html>