Re: [Automake-NG] [PATCH 1/2] [ng] perf: disable GNU make builtin rules, for performance reasons

[Dave Hart]

On Wed, Jun 27, 2012 at 19:31 UTC, Stefano Lattarini wrote:
> On 06/27/2012 07:40 PM, Dave Hart wrote:
>> Yes, good stuff.  Anyone who has debugged Makefiles with GNU make -v
>> has seen the insane number of wasted operations due to combinatorial
>> explosion exploring possible matches with builtin rules.
>>
>> Can Automake be similarly improved to disable GNU make's builtin rules
>> without sacraficing compatibility with less-loved make implementations?
>>
> I think it would be easily doable; it would probably require a configure
> time tough (similar to the one that is done to initialize '@SET_MAKE@').
> Alas, this would have the side effect or rendering a Makefile created
> from a configuration with GNU make early in PATH unusable with non-GNU
> makes.  Not a big deal, but an annoyance nonetheless.

Better than the opposite: I know folks who let configure detect the
native non-GNU 'make' on Solaris and BSD systems, then habitually
invoke 'gmake' not 'make'.  That has not caused trouble, though I
don't advise it.  I generally prefer to use the host 'make' to expose
issues that would not occur with GNU make, but in the more common
scenario of just wanting it to work, I'd suggest MAKE=gmake in the
environment of those who habitually type 'gmake', to inform configure
scripts of the make program that will be used.

> Anybody volunteering a patch?

I'm not, so far.  I'll see how much it itches.

>> If it's not practical for Automake to do this for
>> all packages, how might a maintainer do it for his package without
>> requiring GNU make?
>>
> He could provide a top-level GNUmakefile containing the
>
>    MAKEFLAGS += --no-builtin-rules
>
> line early, and then including the Automake-generated Makefile:
>
>   include ./Makefile
>
> But that will only clobber the built-in rules for builds launched from
> the top-level directory, not from the subdirectories (another good
> reason to switch to a non-recursive make setup).

Thanks.  That approach should work for a recursive setup if each
directory with Makefile.am also has the MAKEFLAGS-altering
GNUmakefile.  From my perspecitve, while it would be nicer if Automake
handled it for me, this solution appeals.  I realize converting to
nonrecursive make would yield correctness and performance wins, but so
far I have been put off by the loss of ability to build only a
subtree.

Cheers,
Dave Hart