Re: [gnu-prog-discuss] Could automake-generated Makefiles required GNU make?

[Bob Friesenhahn]

On Wed, 23 Nov 2011, Dave Hart wrote:
> In other words, Harlan has indicated to me a non-recursive Makefile
> sounds good in eliminating build system bugs due to each directory's
> Makefile having a limited view of the whole, and I agree, but he
> doesn't like the idea of giving up the ability to "make" in, say, the
> ntpd subdirectory and have only ntpd and its prerequisite directories
> components build, and I agree again.  If anyone knows of examples of
> non-recursive Makefile implementations that manage to preserve the
> recursive make property of being able to make in a subdir to make a
> subset, please share so we can learn from their pioneering.

It is certainly possible to build a subset but you have to specify 
full paths to the targets and the current directory needs to be where 
the Makefile is.  Automatically finding the root of the build tree (as 
Mercurial and git do) in order to simplify building a subcomponent is 
something that an improved automake could support.

Unfortunately, 'make' is so flimsy that a non-recursive build (using a 
single 'make' process to produce all build products) is the only way 
for make to know exactly what needs to be done. Unfortunately, 
Automake does not fully support non-recursive builds since it always 
recurses at least once:

% make
make  all-am
make[1]: Entering directory `/scratch/bfriesen/build/GM-16-static'
make[1]: Leaving directory `/scratch/bfriesen/build/GM-16-static'

and each time make recurses, it needs to parse and re-evaluate the 
encountered Makefile from scratch based on what it sees in the 
filesystem.  The costs of recursion (using 'make') are cumulatively 
quite expensive and something that Automake developers should consider 
to be a primary focus to eliminate if Automake will continue to depend 
on a 'make' type tool.  The relative costs of recursion will only 
continue to grow as software projects grow, and as computing systems 
are delivered with tens of CPU cores (which recursion prevents from 
being efficiently used).

Bob

--
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/