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

2013-01-03 Thread Stefano Lattarini
On 01/03/2013 11:40 PM, Eric Blake wrote: > [dropping autoconf] > > On 01/03/2013 03:05 PM, Stefano Lattarini wrote: >> 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 u

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

2013-01-03 Thread 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

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

2013-01-03 Thread 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

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

2013-01-03 Thread 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: $(TA

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

2013-01-03 Thread 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 precio

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

2013-01-03 Thread 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, th

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

2013-01-03 Thread 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 o

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

2013-01-03 Thread 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 pa

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

2013-01-03 Thread 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

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

2013-01-03 Thread Eric Blake
[dropping autoconf] On 01/03/2013 03:05 PM, Stefano Lattarini wrote: > 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_C

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

2013-01-03 Thread 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 INSTAL