[cfe-dev] RFC: Upcoming Build System Changes

[Chris Lattner]

On Oct 28, 2011, at 12:54 AM, Óscar Fuentes wrote:
> A good measure of how fast a set of Makefile are is to run the build
> with all targets up-to-date. Both builds takes a few seconds (3 or so)
> on my Linux quad core box. Whatever improvement can be achieved on this
> seems pretty insignificant.

There are different overheads in different scenarios.  The makefiles get really poor utilization out of a 8 or 16-way machine because of implicit synchronization between different sublibraries.

> Furthermore, recursive make is necessary for automatic generation of
> header dependencies, among other things. The makefiles generated by
> cmake are "partially" recursive for that reason:
> 
> http://www.cmake.org/Wiki/CMake_FAQ#Why_does_CMake_generate_recursive_Makefiles.3F

I don't understand, what does having one makefile per directory have to do with header file generation?

>>>> 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.
>>> 
>>> AFAIK there is a Xcode project file on the LLVM source tree.
>> 
>> Nope, there was once but it was removed a long time ago though.
>> 
>>> Are the
>>> LLVM makefiles used by the Xcode project?
>> 
>> No, it is generated by Cmake.
> 
> So, the cmake-generated Xcode file was considered good enough or… ?

No, not at all.  It's awful.

> Anyways, if you wish to avoid duplicating info on both Makefile and
> CMakeLists.txt there is a simple solution: read and parse the Makefile
> from the corresponding CMakeLists.txt. For instance, if you put the
> library dependencies on the Makefile like this:
> 
> LLVMLIBDEPS := foo zoo bar

I don't see how that is any better than what is being proposed.  You're just moving the complexity from one place to the other, and blocking future improvements that will build on this.

-Chris