Re: bug#13349: Re-execute with the "correct" make implementation

[Stefano Lattarini]

[Dropping Automake-NG]

On 01/04/2013 01:12 AM, Eric Blake wrote:
> On 01/03/2013 04:54 PM, Stefano Lattarini wrote:
>>> Then again, it is autoconf that defines AC_PROG_MAKE_SET which in turn
>>> provides @SET_MAKE@ for substitution in Makefiles;
>>>
>> Right, I had forgotten about that.  I somehow just took it for granted
>> that it was all Automake's doing ...
>>
>> So, it would again be Autoconf that should implement the probe we had
>> talked about, if we decide to go down that road ...
> 
> Well, when it comes to letting MAKE be precious, AC_PROG_MAKE_SET (and
> thus autoconf) is the logical solution.  However, as for actually
> _using_ @SET_MAKE@, that is automake's lib/am/header-vars.am, so I'm
> still inclined to think that a sanity probe belongs best in Automake
> (that is, autoconf provides the tools for finding out what the user
> wants to use as $(MAKE), but automake then takes those tools to turn it
> into a proper Makefile.in with the smartest possible semantics).  In
> fact, we may decide that automake wants to invoke AC_PROG_MAKE_SET, but
> _not_ use @SET_MAKE@, by instead using its own more complete sanity
> checking code.
>
Indeed, this is all very sensible.  Yet I expounded an opposite opinion
just few minutes ago.  Clear indicator it's time to go to bed :-)

Regards,
  Stefano

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

[Eric Blake]

On 01/03/2013 04:54 PM, Stefano Lattarini wrote:
>> Then again, it is autoconf that defines AC_PROG_MAKE_SET which in turn
>> provides @SET_MAKE@ for substitution in Makefiles;
>>
> Right, I had forgotten about that.  I somehow just took it for granted
> that it was all Automake's doing ...
> 
> So, it would again be Autoconf that should implement the probe we had
> talked about, if we decide to go down that road ...

Well, when it comes to letting MAKE be precious, AC_PROG_MAKE_SET (and
thus autoconf) is the logical solution.  However, as for actually
_using_ @SET_MAKE@, that is automake's lib/am/header-vars.am, so I'm
still inclined to think that a sanity probe belongs best in Automake
(that is, autoconf provides the tools for finding out what the user
wants to use as $(MAKE), but automake then takes those tools to turn it
into a proper Makefile.in with the smartest possible semantics).  In
fact, we may decide that automake wants to invoke AC_PROG_MAKE_SET, but
_not_ use @SET_MAKE@, by instead using its own more complete sanity
checking code.

> 
>> so maybe autoconf should be the one that lets $(MAKE) be precious
>> after all.  Does this (relatively untested) patch look like the
>> right thing to do?
>>
> Almost, but with a nit below.

> 
>> +++ w/lib/autoconf/programs.m4
>> @@ -813,10 +813,12 @@ fi
>>  # does not run the test Makefile, we assume that the Make program the
>> user will
>>  # invoke does set $(MAKE).  This is typical, and emitting `MAKE=foomake' is
>>  # always wrong if `foomake' is not available or does not work.
>> +# Calling this macro also marks $MAKE as a precious variable.
>>  AN_MAKEVAR([MAKE], [AC_PROG_MAKE_SET])
>>  AN_PROGRAM([make], [AC_PROG_MAKE_SET])
>>  AC_DEFUN([AC_PROG_MAKE_SET],
>> -[AC_MSG_CHECKING([whether ${MAKE-make} sets \$(MAKE)])
>> +[AC_ARG_VAR([MAKE], [which program will run Makefiles (default make)])
>>
> It's more of a "which program you intend to use to run Makefiles", no?

Indeed.  And I'd want to add testsuite exposure, of course.  I'll take a
bit more time to play with the idea...

And that comment in the autoconf code is interesting - it implies that
there are 'make' that don't set $(MAKE), but that anyone using an
alternative ./configure MAKE=/better/make is probably using a better
make that DOES set $(MAKE); so maybe we can use that to our advantage in
designing a sanity check.  Again, a spy to see what implementations
still fail to set $(MAKE) may be the first prudent course of action.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

[PATCH] AT_TESTED: fix regression in word splitting

[Eric Blake]

Regression introduced in commit 851ef51.

* lib/autotest/general.m4 (AT_TESTED): Rework loop to quote each
element, not the entire argument.
---

This appears to fix the problem (when given AT_TESTED([autoconf automake]),
we were adding "autoconf automake" instead of "autoconf" "automake" to
the list of unique programs), but I'd appreciate an ACK from Paolo to make
sure I didn't break the $EXEEXT handling in the process.

 lib/autotest/general.m4 | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/autotest/general.m4 b/lib/autotest/general.m4
index fff6f61..06d7546 100644
--- a/lib/autotest/general.m4
+++ b/lib/autotest/general.m4
@@ -1794,7 +1794,8 @@ 
m4_defun([AT_ARG_OPTION_ARG],[_AT_ARG_OPTION([$1],[$2],1,[$3],[$4])])
 # must correspond to the version of the package.  PATH should be
 # already preset so the proper executable will be selected.
 m4_define([AT_TESTED],
-[m4_append_uniq_w([AT_tested], ["$1"])])
+[m4_foreach_w([AT_test], [$1],
+  [m4_append_uniq([AT_tested], "m4_defn([AT_test])", [ ])])])


 # AT_COPYRIGHT(TEXT, [FILTER = m4_newline])
-- 
1.8.0.2

Re: bug#13349: Re-execute with the "correct" make implementation

[Stefano Lattarini]

On 01/04/2013 12:35 AM, Bob Friesenhahn wrote:
> On Fri, 4 Jan 2013, Stefano Lattarini wrote:
> 
>> On 01/03/2013 11:53 PM, Nick Bowler wrote:
>>> On 2013-01-03 23:05 +0100, Stefano Lattarini wrote:

   TARGETS = all check clean distclean dist distcheck install uninstall
   .PHONY: $(TARGETS)
   $(TARGETS): ; @gmake $(AM_MAKEFLAGS) $@
>>>
>>> Unfortunately, this kind of wrapper doesn't work particularly well.  If
>>> the user runs something similar to:
>>>
>>>   make -j2 all install
>>>
>>> then the wrapper makefile will happily fork off two independent make
>>> instances in parallel: one running "gmake all" and one running "gmake
>>> install".  The result will probably be catastrophic.
>>>
>> Sigh, so very true.  Adding ".NOTPARALLEL:" could fix this issue though.
>> Assuming that it is portable enough ...
>>
>> At any case, the wrapper would be just a convenience for the most
>> common cases, like:
>>
>>  ./configure && make -j4 check && make install
>>
>> It doesn't have to work in all (or even most) scenarios.
> 
> This problem (use of wrong 'make') does not impact Automake-NG at
> all and it does not seem wise to create a complex solution for a
> problem which is seldom encountered and typically benign.
> 
I agree (but then, I'm biased, because I'd be the one who would have to
try to implement such a complex solution ;-)

But I think it's a fact that a simple "low-tech" solution like encouraging
developers who require GNU make (through Automake-Ng or otherwise) to use
the "GNUmakefile" name for their makefiles would probably give us 90% of
the benefits with 1% of the work.

Regards,
  Stefano

Re: [PATCH] docs: mention $MAKE during configure

[Stefano Lattarini]

On 01/03/2013 11:22 PM, Eric Blake wrote:
> On 01/03/2013 03:10 PM, Stefano Lattarini wrote:
>> On 01/03/2013 10:54 PM, Eric Blake wrote:
>>> Based on a suggestion from Bob Friesenhahn:
>>> https://lists.gnu.org/archive/html/bug-automake/2013-01/msg00017.html
>>>
>>> * doc/install.texi (Defining Variables): Mention that MAKE
>>> can be overridden, and the caveats that come with setting it.
> 
>>> +Another variable to be aware of is @env{MAKE}; many packages allow this
>>> +to be set during @command{configure} in order to request the use of an
>>> +alternative @command{make} implementation (such as GNU make, which is
>>> +often present as @command{gmake}).  However, once an alternative is
>>> +chosen, the resulting Makefile may no longer work with the generic
>>> +@command{make}, so you must make sure to consistently use your
>>> +alternative make.
>>> +
>> s/make/@command{make}/?
> 
> Or maybe s/make/$MAKE/?
> 
Yes, likely clearer.  But shouldn't that be s/make/@code{$MAKE}/ ?  :-)

>>
>> Apart from that possible nit, ACK from me.
> 
> I'll see if anyone else chimes in with a wording suggestion in the next
> 24 hours or so, then push.  We will then see if the gnulib autoupdate
> picks it up, or if I will have to give it a kick to find the new INSTALL.
> 
OK.

Thanks,
  Stefano

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

[Stefano Lattarini]

On 01/04/2013 12:31 AM, Eric Blake wrote:
> On 01/03/2013 03:05 PM, Stefano Lattarini wrote:
>
 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.
> 
> Then again, it is autoconf that defines AC_PROG_MAKE_SET which in turn
> provides @SET_MAKE@ for substitution in Makefiles;
>
Right, I had forgotten about that.  I somehow just took it for granted
that it was all Automake's doing ...

So, it would again be Autoconf that should implement the probe we had
talked about, if we decide to go down that road ...

> so maybe autoconf should be the one that lets $(MAKE) be precious
> after all.  Does this (relatively untested) patch look like the
> right thing to do?
>
Almost, but with a nit below.

> diff --git i/doc/autoconf.texi w/doc/autoconf.texi
> index bb83443..67a862d 100644
> --- i/doc/autoconf.texi
> +++ w/doc/autoconf.texi
> @@ -2208,7 +2208,7 @@ Output
>  @code{$(MAKE)}, define output variable @code{SET_MAKE} to be empty.
>  Otherwise, define @code{SET_MAKE} to a macro definition that sets
>  @code{$(MAKE)}, such as @samp{MAKE=make}.  Calls @code{AC_SUBST} for
> -@code{SET_MAKE}.
> +@code{SET_MAKE}, and also calls @code{AC_ARG_VAR} for @code{MAKE}.
>  @end defmac
> 
>  If you use this macro, place a line like this in each @file{Makefile.in}
> diff --git i/lib/autoconf/programs.m4 w/lib/autoconf/programs.m4
> index f7af8b5..b6a8f78 100644
> --- i/lib/autoconf/programs.m4
> +++ w/lib/autoconf/programs.m4
> @@ -813,10 +813,12 @@ fi
>  # does not run the test Makefile, we assume that the Make program the
> user will
>  # invoke does set $(MAKE).  This is typical, and emitting `MAKE=foomake' is
>  # always wrong if `foomake' is not available or does not work.
> +# Calling this macro also marks $MAKE as a precious variable.
>  AN_MAKEVAR([MAKE], [AC_PROG_MAKE_SET])
>  AN_PROGRAM([make], [AC_PROG_MAKE_SET])
>  AC_DEFUN([AC_PROG_MAKE_SET],
> -[AC_MSG_CHECKING([whether ${MAKE-make} sets \$(MAKE)])
> +[AC_ARG_VAR([MAKE], [which program will run Makefiles (default make)])
>
It's more of a "which program you intend to use to run Makefiles", no?

Regards,
  Stefano

Re: [GNU Autoconf 2.69.59-adc84] testsuite: 132 355 failed

[Eric Blake]

On 12/31/2012 04:17 PM, Eric Blake wrote:

>>
>>  132: autotest.at:300Tested programs
>>   autotest
> 
> I've reproduced this locally, and hope to have it fixed soon (eek, my
> day is almost over, and I'm still stalled with getting m4 1.4.17
> released, because that turned up some needed gnulib work; so it looks
> like autoconf 2.70 will have a 2013 copyright, rather than my original
> goal of releasing today).

'git bisect' points to this commit as the culprit:

commit 851ef517963d1e1966c4082530d5e87ba0a415ab
Author: Paolo Bonzini 
Date:   Fri Dec 7 14:00:19 2012 +0100

autotest: enable usage of EXEEXT in AT_TESTED

Paolo, can you also take a look, if I don't get it patched first?

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: bug#13349: Re-execute with the "correct" make implementation

[Bob Friesenhahn]

On Fri, 4 Jan 2013, Stefano Lattarini wrote:


On 01/03/2013 11:53 PM, Nick Bowler wrote:

On 2013-01-03 23:05 +0100, Stefano Lattarini wrote:


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


Unfortunately, this kind of wrapper doesn't work particularly well.  If
the user runs something similar to:

  make -j2 all install

then the wrapper makefile will happily fork off two independent make
instances in parallel: one running "gmake all" and one running "gmake
install".  The result will probably be catastrophic.


Sigh, so very true.  Adding ".NOTPARALLEL:" could fix this issue though.
Assuming that it is portable enough ...

At any case, the wrapper would be just a convenience for the most
common cases, like:

 ./configure && make -j4 check && make install

It doesn't have to work in all (or even most) scenarios.


This problem (use of wrong 'make') does not impact Automake-NG at all 
and it does not seem wise to create a complex solution for a problem 
which is seldom encountered and typically benign.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

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

[Eric Blake]

On 01/03/2013 03:05 PM, Stefano Lattarini wrote:

>>> 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.

Then again, it is autoconf that defines AC_PROG_MAKE_SET which in turn
provides @SET_MAKE@ for substitution in Makefiles; so maybe autoconf
should be the one that lets $(MAKE) be precious after all.  Does this
(relatively untested) patch look like the right thing to do?

diff --git i/doc/autoconf.texi w/doc/autoconf.texi
index bb83443..67a862d 100644
--- i/doc/autoconf.texi
+++ w/doc/autoconf.texi
@@ -2208,7 +2208,7 @@ Output
 @code{$(MAKE)}, define output variable @code{SET_MAKE} to be empty.
 Otherwise, define @code{SET_MAKE} to a macro definition that sets
 @code{$(MAKE)}, such as @samp{MAKE=make}.  Calls @code{AC_SUBST} for
-@code{SET_MAKE}.
+@code{SET_MAKE}, and also calls @code{AC_ARG_VAR} for @code{MAKE}.
 @end defmac

 If you use this macro, place a line like this in each @file{Makefile.in}
diff --git i/lib/autoconf/programs.m4 w/lib/autoconf/programs.m4
index f7af8b5..b6a8f78 100644
--- i/lib/autoconf/programs.m4
+++ w/lib/autoconf/programs.m4
@@ -813,10 +813,12 @@ fi
 # does not run the test Makefile, we assume that the Make program the
user will
 # invoke does set $(MAKE).  This is typical, and emitting `MAKE=foomake' is
 # always wrong if `foomake' is not available or does not work.
+# Calling this macro also marks $MAKE as a precious variable.
 AN_MAKEVAR([MAKE], [AC_PROG_MAKE_SET])
 AN_PROGRAM([make], [AC_PROG_MAKE_SET])
 AC_DEFUN([AC_PROG_MAKE_SET],
-[AC_MSG_CHECKING([whether ${MAKE-make} sets \$(MAKE)])
+[AC_ARG_VAR([MAKE], [which program will run Makefiles (default make)])
+AC_MSG_CHECKING([whether ${MAKE-make} sets \$(MAKE)])
 set x ${MAKE-make}
 ac_make=`AS_ECHO(["$[2]"]) | sed 's/+/p/g; s/[[^a-zA-Z0-9_]]/_/g'`
 AC_CACHE_VAL(ac_cv_prog_make_${ac_make}_set,


-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: bug#13349: Re-execute with the "correct" make implementation

[Stefano Lattarini]

On 01/03/2013 11:53 PM, Nick Bowler wrote:
> On 2013-01-03 23:05 +0100, Stefano Lattarini wrote:
>>
>>   TARGETS = all check clean distclean dist distcheck install uninstall
>>   .PHONY: $(TARGETS)
>>   $(TARGETS): ; @gmake $(AM_MAKEFLAGS) $@
> 
> Unfortunately, this kind of wrapper doesn't work particularly well.  If
> the user runs something similar to:
> 
>   make -j2 all install
> 
> then the wrapper makefile will happily fork off two independent make
> instances in parallel: one running "gmake all" and one running "gmake
> install".  The result will probably be catastrophic.
>
Sigh, so very true.  Adding ".NOTPARALLEL:" could fix this issue though.
Assuming that it is portable enough ...

At any case, the wrapper would be just a convenience for the most
common cases, like:

  ./configure && make -j4 check && make install

It doesn't have to work in all (or even most) scenarios.

Regards,
  Stefano

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

[Nick Bowler]

On 2013-01-03 23:05 +0100, Stefano Lattarini wrote:
> On 01/03/2013 10:34 PM, Eric Blake wrote:
[...]
> > 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) $@

Unfortunately, this kind of wrapper doesn't work particularly well.  If
the user runs something similar to:

  make -j2 all install

then the wrapper makefile will happily fork off two independent make
instances in parallel: one running "gmake all" and one running "gmake
install".  The result will probably be catastrophic.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: [PATCH] docs: mention $MAKE during configure

[Eric Blake]

On 01/03/2013 03:10 PM, Stefano Lattarini wrote:
> On 01/03/2013 10:54 PM, Eric Blake wrote:
>> Based on a suggestion from Bob Friesenhahn:
>> https://lists.gnu.org/archive/html/bug-automake/2013-01/msg00017.html
>>
>> * doc/install.texi (Defining Variables): Mention that MAKE
>> can be overridden, and the caveats that come with setting it.

>> +Another variable to be aware of is @env{MAKE}; many packages allow this
>> +to be set during @command{configure} in order to request the use of an
>> +alternative @command{make} implementation (such as GNU make, which is
>> +often present as @command{gmake}).  However, once an alternative is
>> +chosen, the resulting Makefile may no longer work with the generic
>> +@command{make}, so you must make sure to consistently use your
>> +alternative make.
>> +
> s/make/@command{make}/?

Or maybe s/make/$MAKE/?

> 
> Apart from that possible nit, ACK from me.

I'll see if anyone else chimes in with a wording suggestion in the next
24 hours or so, then push.  We will then see if the gnulib autoupdate
picks it up, or if I will have to give it a kick to find the new INSTALL.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] docs: mention $MAKE during configure

[Stefano Lattarini]

On 01/03/2013 10:54 PM, Eric Blake wrote:
> Based on a suggestion from Bob Friesenhahn:
> https://lists.gnu.org/archive/html/bug-automake/2013-01/msg00017.html
> 
> * doc/install.texi (Defining Variables): Mention that MAKE
> can be overridden, and the caveats that come with setting it.
> ---
> 
> How does this look?
> 
>  doc/install.texi | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/install.texi b/doc/install.texi
> index 4c2ffb5..bb08786 100644
> --- a/doc/install.texi
> +++ b/doc/install.texi
> @@ -5,7 +5,7 @@
> 
>  @unnumbered Installation Instructions
> 
> -Copyright @copyright{} 1994-1996, 1999-2002, 2004-2012 Free Software
> +Copyright @copyright{} 1994-1996, 1999-2002, 2004-2013 Free Software
>  Foundation, Inc.
> 
>  Copying and distribution of this file, with or without modification, are
> @@ -371,6 +371,14 @@ Defining Variables
>  CONFIG_SHELL=/bin/bash ./configure CONFIG_SHELL=/bin/bash
>  @end example
> 
> +Another variable to be aware of is @env{MAKE}; many packages allow this
> +to be set during @command{configure} in order to request the use of an
> +alternative @command{make} implementation (such as GNU make, which is
> +often present as @command{gmake}).  However, once an alternative is
> +chosen, the resulting Makefile may no longer work with the generic
> +@command{make}, so you must make sure to consistently use your
> +alternative make.
> +
s/make/@command{make}/?

Apart from that possible nit, ACK from me.

Thanks,
  Stefano

Re-execute with the "correct" make implementation

[Stefano Lattarini]

[+cc Automake-NG]

Reference: 

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

[PATCH] docs: mention $MAKE during configure

[Eric Blake]

Based on a suggestion from Bob Friesenhahn:
https://lists.gnu.org/archive/html/bug-automake/2013-01/msg00017.html

* doc/install.texi (Defining Variables): Mention that MAKE
can be overridden, and the caveats that come with setting it.
---

How does this look?

 doc/install.texi | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/doc/install.texi b/doc/install.texi
index 4c2ffb5..bb08786 100644
--- a/doc/install.texi
+++ b/doc/install.texi
@@ -5,7 +5,7 @@

 @unnumbered Installation Instructions

-Copyright @copyright{} 1994-1996, 1999-2002, 2004-2012 Free Software
+Copyright @copyright{} 1994-1996, 1999-2002, 2004-2013 Free Software
 Foundation, Inc.

 Copying and distribution of this file, with or without modification, are
@@ -371,6 +371,14 @@ Defining Variables
 CONFIG_SHELL=/bin/bash ./configure CONFIG_SHELL=/bin/bash
 @end example

+Another variable to be aware of is @env{MAKE}; many packages allow this
+to be set during @command{configure} in order to request the use of an
+alternative @command{make} implementation (such as GNU make, which is
+often present as @command{gmake}).  However, once an alternative is
+chosen, the resulting Makefile may no longer work with the generic
+@command{make}, so you must make sure to consistently use your
+alternative make.
+
 @node configure Invocation
 @section @command{configure} Invocation

-- 
1.8.0.2

Re: bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?

[Eric Blake]

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.

> 
>> 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).

>  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?  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?

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?

[Stefano Lattarini]

Hi Eric.

On 01/03/2013 09:40 PM, Eric Blake wrote:
> [adding bug-autoconf, as owner of the source that becomes the generic
> GNU INSTALL file]
> 
> On 01/03/2013 01:33 PM, Bob Friesenhahn wrote:
>> On Thu, 3 Jan 2013, Stefano Lattarini wrote:

 It is a problem that MAKE is not mentioned in the standard
 GNU INSTALL file, or in Automake's own INSTALL file.

>>> The latter is not surprising, since Automake's INSTALL file is
>>> merely a copy of the generic GNU one.
>>>
 If this variable was never mentioned by any instructional text,
 users can't be expected to ever use it.

>>> This makes sense?  Care to attempt a patch?  I'm not going to
>>> do it myself, I must admit.
>>
>> If Automake-dependent packages are dependent on MAKE, then it seems that
>> mention of MAKE should be added to the standard GNU INSTALL file (not
>> just Automake's copy).
>>
>> Previous to use by Automake in configure scripts, MAKE was an
>> environment variable used for internal communication from a parent make
>> process to a subordinate make process and set by make itself.
> 
> 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.

> 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).  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.

Regards,
  Stefano

Re: bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?

[Eric Blake]

[adding bug-autoconf, as owner of the source that becomes the generic
GNU INSTALL file]

On 01/03/2013 01:33 PM, Bob Friesenhahn wrote:
> On Thu, 3 Jan 2013, Stefano Lattarini wrote:
>>>
>>> It is a problem that MAKE is not mentioned in the standard
>>> GNU INSTALL file, or in Automake's own INSTALL file.
>>>
>> The latter is not surprising, since Automake's INSTALL file is
>> merely a copy of the generic GNU one.
>>
>>> If this variable was never mentioned by any instructional text,
>>> users can't be expected to ever use it.
>>>
>> This makes sense?  Care to attempt a patch?  I'm not going to
>> do it myself, I must admit.
> 
> If Automake-dependent packages are dependent on MAKE, then it seems that
> mention of MAKE should be added to the standard GNU INSTALL file (not
> just Automake's copy).
> 
> Previous to use by Automake in configure scripts, MAKE was an
> environment variable used for internal communication from a parent make
> process to a subordinate make process and set by make itself.

So what's the verdict - do we (want to) support the user overriding
MAKE, and therefore document that in INSTALL?  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'?

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature