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

Óscar Fuentes ofv at wanadoo.es
Tue Nov 1 16:03:56 PDT 2011


greened at obbligato.org (David A. Greene) writes:

> Óscar Fuentes <ofv at wanadoo.es> writes:
>
>> greened at obbligato.org (David A. Greene) writes:
>>
>>> Hmm...it's a build system, right?  There's not much to add, really.
>>> Build systems should be really simple.  All they need is dependencies
>>> and rules to build stuff.
>>
>> Oh, yes, sure, you're right. <g>
>
> Can't tell if you're being snarky or not...

Well, I was the guy who created and maintained the LLVM cmake build, so
I'll let you guess :-)

And before you say "yes, but cmake sucks and hence it is more
unpleasant/difficult/inconvenient/whatever" I'll mention that cmake
makes things immensely better than autoconf+make (or make alone, if you
wish.)

>>> What sorts of features can you imagine we'd want to add?
>>
>> That's a question for Daniel. He is who's saying that his proposal will
>> make the build(s) more flexible, extensible, etc.
>
> Er?  This is your statement, isn't it?
>
>   > In fact, as your proposed system deals with both build systems it acts
>   > as a common denominator, thus restricting the evolution of them, as some
>   > features that could be easy to implement on cmake but difficult on
>   > `make' now must go through your scripts, which act as a deterrent.
>
> I'm trying to understand what you are worried about WRT a "common
> denominator."

Since both LLVM builds exists they do not evolve in parallel: sometimes
a feature is implemented on a build but not on the other, other times a
new feature is required on both builds (think the new test system.) If
the builds are unrelated, people who use the cmake build can improve it
without caring about the `make' build (and vice-versa) and, on the same
way, required features can be implemented on one system without caring
about the other (that was the case for the new test system, which took a
long time to appear on the cmake build.) As Daniel's proposal is,
essentially, something that takes care of what is common to both
systems, it is not so clear that afterwards one can work on a system
without caring about the other. And it conditions how things are done:
anyone who works on make/cmake must keep on mind Daniel's requirements
and abide to them.




More information about the llvm-dev mailing list