[cfe-dev] RFC: Upcoming Build System Changes

[Douglas Gregor]

On Oct 27, 2011, at 10:55 PM, Chris Lattner wrote:
> On Oct 27, 2011, at 6:34 PM, Chandler Carruth wrote:
> 
>> I have a very high level comment, and you may be able to directly shed light on it before I dig into a lot more detail.
>> 
>> Why not simply standardize on CMake? It's not my favorite tool, but it seems to work well, we have established usage of it, and several people involved in the project who understand how it works. It doesn't seem like a significantly more burdensome dependency than Python when developing, and it remains possible to build installable packages for the casual hacker.
>> 
>> I can see some objections to CMake, but it's not clear to me that they should carry the day. I'm also probably missing some.
> 
> There are several major problems with CMake IMO:
> 
> 1. It generates really slow build systems.

Outside of Xcode projects (your issue #2), do you have any evidence to support this claim? We've measured before that the CMake-generated makefiles are faster than the current makefile system. Anecdotally, CMake's generated makefiles scaled very nicely to the multi-library monstrosity that is Boost. (They beat the crap out of Boost.Build, but that's not exactly hard to do).

> 2. The build system generated by cmake is absolute garbage, at least for Xcode.  The build times of it are really bad, and having to work with it in the IDE is even more terrible.

CMake's Xcode project generator is quite horrible. Daniel seems to think that it can't ever be done well, but I disagree: that generator is so crusty that a couple of hours would likely produce a huge improvement. Alas, I don't have the spare cycles to prove Daniel wrong.

Regardless, Daniel's proposal doesn't fix this, either. CMake will still generate crappy Xcode projects with his system.

CMake's Visual Studio and makefile projects work quite well, in my experience. Why do you think otherwise?

> 3. I'd really like us to get to explicit and principled library dependencies, where the build horks if you accidentally add a library dependency.  Without this, I don't see how LLVM will ever scale up.

CMake already has explicit library dependencies, and the CMake build breaks when they're wrong. So CMake has already made the world a better place :)

By "principled", I assume you mean that all dependencies are spelled out rather than getting them transitively. This is new functionality that's fairly easy to add to both CMake and Daniel's tool.

> 4. I'd really like us to move in a direction where LLVM is less monolithic.  Right now "llvm" contains all the MC stuff, all the targets, all the mid-level optimizer, etc.  Adding a new LLVM MC-based linker will cause it to naturally get dropped into the llvm project, which is great but not helping the monolithicness. :)

CMake can support different project organizations. I'm currently using CMake with separate projects for Clang and LLVM, and it works just fine. Why do you think it can't?

So, #3 and #4 aren't CMake issues at all. #1 and #2 seem only to apply to CMake's Xcode project generator, which is a tiny fraction of what CMake provides.

	- Doug