[LLVMdev] [cfe-dev] RFC: Upcoming Build System Changes

[Daniel Dunbar]

I'm going to briefly summarize my responses here.

On Fri, Oct 28, 2011 at 9:56 AM, Chris Lattner <clattner at apple.com> wrote:
> On Oct 28, 2011, at 12:54 AM, Óscar Fuentes wrote:
>> 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.

I believe this is one of the key points.

In LLVM, we have a lot of domain specific structure in the project.
*Any* build system is going to have to codify that information.
Codifying it *informally* inside CMake / Make / anything else is no
different than codifying it in a new system, but:
 (a) a clear, explicit system makes it easier to understand exactly
what is supported
 (b) it provides a good place to hang documentation. Users can clearly
differentiate between the domain specific LLVM structure and the CMake
implementation details or the make implementation details.

The *ONLY* good reason to put this information inside CMake instead of
external files is as a way to avoid a Python dependency at build time.
However, the cost of doing so is incredibly high:
 * code to use this information in CMake must be written in CMake, a
horrible horrible language which I in no way whatsoever believe should
be inflicted on any more LLVM developers than necessary.
 * other tools to use this information must parse CMake files. Either
they parse some incomplete subset (which then must be documented,
etc.) or they have to deal more with the (see above) horrible horrible
CMake language.


The only other argument on this thread I consider to have significant
weight is whether we should standardize on CMake. I am strongly
against this:

 * CMake is a very heavy dependency to standardize on. Adding external
files that clearly codify how to build the project allows anyone to
reimplement tools to build the project, if necessary, but that is not
at all true of dealing with CMake.

 * I don't think CMake is good enough. I agree it solves problems, but
I want to use great tools, not ones that work. In particular:
    (a) The Xcode projects are horrible.
    (b) The language is horrible.
    (c) This doesn't solve any other nice problems:
          (i) It doesn't make it easier to play with other build
systems (like Ninja, or gyp).
          (ii) It doesn't make it easier to write tools for LLVM. For
example, my system would make it easy to add tools to operate on all
the source files. For example, to add tools to run style checkers on
all the code, or add static analyzer build steps.

 * many many large projects end up with meta build systems, and they
usually are happy with it, and they usually have good reasons for
doing so.

 * This is largely a separate (but related) topic. If you really want
to seriously argue for it, please move it to a different thread (where
I will continue to strongly oppose it) and try to convince Chris it is
the Right Thing (tm). Otherwise, we are as today maintaining multiple
build systems. Even if we wanted to move to CMake, lots of users have
dependencies on the current Makefiles so we will still have to keep
them working for some time to come.

Overall, I believe that my system will *reduce the work* and *improve
the experience* of the majority of LLVM developers. The cost we are
paying for this gain is (a) my time, and (b) a python dependency. As I
said before, we already have (b) for running tests, which no one who
has complained about this have given credence to. In my opinion,
although this adds a new system, but it is actually reducing
complexity because the system becomes (a) better documented, (b) more
understandable, and (c) more explicit.

 - Daniel

> -Chris
>
>