[Top][All Lists]

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

RE: new feature idea: ingesting processed rulesets

From: Zoltán Turányi
Subject: RE: new feature idea: ingesting processed rulesets
Date: Wed, 24 May 2023 06:37:08 +0000

Hi David,

Thanks for your informative response, comments and references.

I do see your point (and in a way wanted to attack the separation of the DAG 
myself with this topic).
However, the advice to place all make information into a top-level Makefile.am 
is not always practical. The point of subdirectories is isolation, this is why 
we put files into separate directories. The dependencies between such 
directories would be best placed besides them not in some central makefile.

Henrik mentioned inclusion. I find that a more attractive solution as it seems 
to combine the best of both worlds: it has both isolation and results in a 
single DAG. Do you think autotools is possible to instrument to do that? Any 
advice on how to set it up?


-----Original Message-----
From: David A. Wheeler <dwheeler@dwheeler.com> 
Sent: Tuesday, May 23, 2023 8:32 PM
To: Henrik Carlqvist <hc94@poolhem.se>; bug-make <bug-make@gnu.org>
Cc: Zoltán Turányi <zoltan.turanyi@ericsson.com>
Subject: Re: new feature idea: ingesting processed rulesets

> On Tue, 23 May 2023 12:07:51 -0400
> "David A. Wheeler" <dwheeler@dwheeler.com> wrote: 
>> The solution is to *NOT* use recursive make. Have *ONE* process run 
>> the makefile, with the correct data. Now you can enable parallel 
>> jobs, and have it run really quickly, because the make process has the 
>> correct information.
>> Using this approach you can routinely run large make jobs in a 
>> fraction of a second.

> On May 23, 2023, at 1:16 PM, Henrik Carlqvist <hc94@poolhem.se> wrote:
> If you prefer to do it that way, you can have your top Makefile 
> include all sub.mk files in the directory structure that it is able to find.

Yes, absolutely. The point is that you want a single process to have all the 
information, so it can perform the correct actions... multiple *files* is fine. 
As noted in "Recursive Make Considered Harmful" by Peter Miller <"Recursive 
Make Considered Harmful" by Peter Miller, e.g.:
"The above [long list of problems] is based on one simple action: the DAG was 
artificially separated into incomplete pieces. This separation resulted in all 
of the problems familiar to recursive make builds.
Did make get it wrong? No. This is a case of the ancient GIGO principle: 
Garbage In, Garbage Out . Incomplete Makefiles are wrong Makefiles.
To avoid these problems, don’t break the DAG into pieces; instead, use one 
Makefile [process] for the entire project...
modern make implementations have include statements. . By including a relevant 
fragment from each module, the total size of the Makefile and its include files 
need be no larger than the total size of the Makefile s in the recursive case."

I find that "whole project" Makefiles are *incredibly* fast. I auto-generate 
dependencies from source in larger projects, but store them in ".d" files that 
depend on their sources; thus, regeneration of dependencies only happens when 
it needs to happen. Modern filesystems (with modern caches) can load all those 
make fragments in a blink of an eye. And they completely eliminate the endless 
problems of recursive make approaches.

Here are some things you might find useful for using make well:
"A Super-Simple Makefile for Medium-Sized C/C++ Projects" 
My make-booster: 

--- David A. Wheeler

reply via email to

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