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

On Fri, Oct 28, 2011 at 9:56 AM, Óscar Fuentes <ofv at wanadoo.es>
wrote:
> Reid Kleckner <reid.kleckner at gmail.com> writes:
<snip>
> Keep in mind that, if Dan goes ahead his plans, tinkering on any build
> system would require knowledge of both of them plus the python
> scripts. That's adding complexity, quite a lot.
This argument might make sense if you already know CMake.

However, most developers do not and it is much easier to learn Python
than CMake.

We currently have about 7k lines of CMake code in LLVM/Clang. My
python scripts to deal with my proposal are significantly smaller than
that.

 - Daniel
>
> [snip]
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>

Daniel Dunbar <daniel at zuster.org> writes:
> On Fri, Oct 28, 2011 at 9:56 AM, Óscar Fuentes <ofv at wanadoo.es>
wrote:
>> Reid Kleckner <reid.kleckner at gmail.com> writes:
>
> <snip>
>
>> Keep in mind that, if Dan goes ahead his plans, tinkering on any build
>> system would require knowledge of both of them plus the python
>> scripts. That's adding complexity, quite a lot.
>
> This argument might make sense if you already know CMake.
>
> However, most developers do not and it is much easier to learn Python
> than CMake.
That's your opinion. And you are assuming that what you propose will not
require CMake (nor `make') knowledge for maintainance, something that I
strongly doubt.

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.
> We currently have about 7k lines of CMake code in LLVM/Clang. My
> python scripts to deal with my proposal are significantly smaller than
> that.
This is unfair, bordering disinformation, I'll say. Most of those lines
are plain lists of file names and library dependency info. Then comes
support for user options, then platform tests. The actual amount of
cmake code is a tiny fraction of those 7k lines.

Óscar Fuentes <ofv at wanadoo.es> writes:
>> However, most developers do not and it is much easier to learn Python
>> than CMake.
>
> That's your opinion.
It's my experience.  Every time I look at CMake my head hurts.  :)
> And you are assuming that what you propose will not require CMake (nor
> `make') knowledge for maintainance, something that I strongly doubt.
Oh, it probably will and I agree it may be adding some complexity.
> 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.
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.  I don't think Daniel is considering
implementing autoconf-like capability, for example.

And make is extremely powerful.  Most projects don't even come close to
exploiting its capability.

What sorts of features can you imagine we'd want to add?

                               -Dave