[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 00/22] Towards a non-recursive build system for coreutils?

From: Jim Meyering
Subject: Re: [PATCH 00/22] Towards a non-recursive build system for coreutils?
Date: Sat, 01 Sep 2012 08:13:55 +0200

Stefano Lattarini wrote:

> On 08/31/2012 08:42 PM, Jim Meyering wrote:
>> Stefano Lattarini wrote:
>>> On 08/31/2012 08:28 PM, Bob Proulx wrote:
>>>> Jim Meyering wrote:
>>>>> As expected, the build now seems faster.
>>>>> I haven't yet measured it.
>>>> Not wanting to ask work of you but it would be great if when all was
>>>> said and done there was a posting of the build time that changed due
>>>> to the build infrastructure change from recursive to non-recursive
>>>> make.  It would be an interesting datapoint.
>>> FWIW, I'm helping with this conversion because I believe non-recursive
>>> builds offer improved clarity, correctness and reliability.  The fact
>>> that they might also end up offering enhanced performance is just an
>>> extra (albeit valuable) perk, not a motivating factor.
>> Of course, one of us will time it once it's all done.
>> We'll also need a NEWS entry, and I hope Stefano will write it.
>> For reference, I look very favorably on converting all
>> packages to non-recursive make.  Bison was the first GNU
>> project that I noticed doing this.  I liked what I saw there
>> so much that I converted cppi's build system as a proof-of-concept.
>> It's a lot smaller and simpler, so you can see better what's required
>> there.  In spite of that, I'm sure it can be cleaned up even more.
> An important (and big) step would be to enhance gnulib to create
> Makefile fragments that can be used in non-recursive packages.
> I see tha, as of today, bison and cppi works around the gnulib
> limitation by *heavily* massaging its generated
> Which is quite brittle and not at all scalable (albeit it certainly
> was the easiest and quickest way to implement the de-recursion of
> those package; and I must admit that, being in Akim's or Jim's
> place, I'd have done the same).

Precisely.  For the first project (bison), or the second, a small
proof-of-concept (cppi), it would have been hard to justify diving
into gnulib-tool's lib/ generation code.  Now that coreutils
is also in play, I think one of us will make the time.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]