Subject: Re-execute with the "correct" make implementation

From: Stefano Lattarini <[email-masked]>
Date: Thu, 03 Jan 2013 23:05:29 +0100

[+cc Automake-NG]

Reference: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13349#31>

On 01/03/2013 10:34 PM, Eric Blake wrote:
> On 01/03/2013 02:14 PM, Stefano Lattarini wrote:
>>> So what's the verdict - do we (want to) support the user overriding
>>> MAKE, and therefore document that in INSTALL?
>>>
>> Indeed, we should warn the user that if he configures an Autotools-based
>> package with MAKE set in the environment (or passed on the command line),
>> that he must use that same $MAKE to build the package; if this doesn't
>> happen, semi-random (albeit unlikely) failures can crop up.
> 
> Okay, I'll whip up that autoconf patch.
>
Thanks.

>>> For that matter, should
>>> autoconf (and/or automake) mark MAKE as a precious variable, so that it
>>> gets listed in './configure --help', and so 'MAKE=gmake ./configure' has
>>> the same results as './configure MAKE=gmake'?
>>>
>> Yeah, probably AM_INIT_AUTOMAKE should enhance the configure help message
>> to report the "quirky" role of $MAKE (patches welcome).
> 
> I'll think about an automake patch to make it precious (at this point,
> I'm thinking that the use of MAKE is too closely tied to automake, and
> that autoconf itself has no business in setting MAKE as precious, only
> documenting in the generic INSTALL that MAKE is often important because
> of automake).
>
Yes, this seems the best approach.

>>  As for $MAKE
>> becoming a precious variable, it cannot certainly hurt, but is not truly
>> relevant either, since the user still has to invoke $MAKE himself, and
>> configure cannot help him there.
> 
> Hmm, that goes back to one of the questions we asked about Automake-NG -
> is it possible to write a generic makefile that merely forwards all
> requests to gmake, and where all of the real magic of Automake-NG is in
> GNUMakefile, so that even if the user types 'make all' they still end up
> running 'gmake all' under the hood?
>
For usual targets, that is easy.  I don't even think that must be done
at Automake-NG level; one can simply use 'GNUmakefile.am' as Automake-NG
input file (instead of the usual 'Makefile.am'), add 'GNUmakefile' to
an AC_CONFIG_FILES invocation, and then hand-write a simple Makefile
acting as a thin wrapper:

  TARGETS = all check clean distclean dist distcheck install uninstall
  .PHONY: $(TARGETS)
  $(TARGETS): ; @gmake $(AM_MAKEFLAGS) $@

The super-nice developer can even turn this Makefile into a Makefile.in,
use '@GNU_MAKE@' rather than simply 'gmake', and (from configure) look
for a GNU make implementation in the system and AC_SUBST '@GNU_MAKE@' to
its absolute path.

> In fact, is it possible to write a
> Makefile that compares the encoded settings of $(MAKE) set at configure
> time, against the current value of $(MAKE) from the current make
> implementation running the makefile, and which can re-execute and/or
> loudly abort if there is a mismatch?
> 
Loudly aborting on such a mismatch would likely be possible I think, by
adding something like this to the footer.am:

    all check clean distclean dist distcheck install uninstall: am--no-make-mismatch
    am--no-make-mismatch:
        @test '$(MAKE)' = '@MAKE@' || fatal mismatch

Well, almost: currently, if the make implementation in use (as specified
by ${MAKE-make}) doesn't set $(MAKE) automatically, configure code generated
by AM_INIT_AUTOMAKE causes $(MAKE) to be explicitly defined to '@MAKE@' in
the generated Makefile.in (to be later subst'ed by 'config.status' in the
resulting Makefile).  But this probably happens only with old broken make
implementations (and maybe configure could start simply punting when such
a borked make is detected?).

In conclusion: if this approach can be made to work, a patch would be
very welcome, and could go directly into 1.13.2 (as the change would not
be invasive in the least, and would offer more reliable build systems).

Thanks,
  Stefano