bug-make
[Top][All Lists]
Advanced

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

Re: new feature idea: ingesting processed rulesets


From: David A. Wheeler
Subject: Re: new feature idea: ingesting processed rulesets
Date: Tue, 23 May 2023 12:07:51 -0400


> On May 23, 2023, at 5:13 AM, Zoltán Turányi <zoltan.turanyi@ericsson.com> 
> wrote:
> 
> Hello,
>  
> I have looked through the mail archives and the manual (to some degree of 
> thoroughness) and have not found this idea yet. If, it exists, I apologize 
> for the spam in advance.
>  
> I use make with autotools in multiple directories and have observed that 
> parallel builds are limited to each directory, as autotools invoked make 
> separately for each directory.

This is not a requirement of autotools. Instead, it's a common mistake made by 
users of automake.

Re-running "make" in each subdirectory is called "recursive make". Recursive 
make *seems* reasonable,
but it's terrible. What it *means* is that each make has incorrect (incomplete) 
information.
In *practice* this produces makefiles that are fragile, do the wrong thing, and 
take a long time to run. See:
 "Recursive Make Considered Harmful" by Peter Miller, e.g.:
https://accu.org/journals/overload/14/71/miller_2004/

I discuss how to avoid recursive make (and what to do instead) in my autotools 
tutorial:
https://www.youtube.com/watch?v=4q_inV9M_us

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.

You don't need to rig make to work with a bad design; change the design.

--- David A. Wheeler




reply via email to

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