[Top][All Lists]

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

Re: Bug-make Digest, Vol 135, Issue 17

From: Bjoern Michaelsen
Subject: Re: Bug-make Digest, Vol 135, Issue 17
Date: Mon, 24 Feb 2014 18:50:13 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Hi Paul,

On Fri, Feb 21, 2014 at 12:00:49PM -0500, address@hidden wrote:
> That is extremely limiting.  About the only kind of makefile that looks
> like that would be makefiles generated by compilers for dependency
> detection, and not even all of those (for example, the generator
> couldn't use the equivalent of the GCC -MT flag with a variable value,
> etc.)

Yes. But of course for any bigger C/C++ project, although a rather specific
usecase, it makes up the majority of the source to parse. _If_ LibreOffice
wouldnt already do some tricks, parsing the 13GB of generated dependencies
would dwarf anything else in makes performance. And even with the tricks we do
to reduce the deps to parse to some <350MB it still eats half of the time[1].

And while this is an extreme case, I think other non-trivial projects are hit
by this too. As other build systems like ninja do caching, they likely will
consider to move away from make.

> Further, it assumes an environment where all the dependency information
> is collected into a single large file, which is not how these things are
> done normally.  I understand that you've "post-processed" the dependency
> file, but obviously most will not do that.


> Also, this adds an entirely new dimension to make which has never existed
> before: history. [...]  I'm not adverse to adding history, per se, but it's a
> big step.

Understood. And yes, there are certainly other ways to attack this issue too.
Its just that this one works for us. ;)

> I get that this is a big performance boost for you but I'm concerned
> that it's not a generically useful feature.

Right. No hard feelings then. ;) We'll keep LibreOffice buildable on all
released plain GNU makes (3.81 and up) for a long time. This feature will only
be an optimization for developers caring about incremental build time, thus
we'll keep in a local branch.



[1] Assuming this would be linear: A noop incremental build that with
    depcaching would take ~8 seconds would then take ~4 minutes.

Bjoern Michaelsen
Member, Board of Directors
Key fingerprint = C8BE 3F1F 92CB 2646 17FE  361D DCD9 C191 E48D BF5F
The Document Foundation, Kurfürstendamm 188, 10707 Berlin
Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts
Legal details: http://www.documentfoundation.org/imprint

reply via email to

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