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

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

[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

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

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

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

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

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

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

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

[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

[+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

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

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 passe

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

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

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

[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 INSTAL

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

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 mention

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

On 01/03/2013 08:56 PM, Bob Friesenhahn wrote: > On Thu, 3 Jan 2013, Stefano Lattarini wrote: >>> >>> How would you know the make program that the user will actually use? >>> >> Assume it is either the default one, or that $MAKE is passed to >> configure. Automake-generated configure code has been

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

On Thu, 3 Jan 2013, Stefano Lattarini wrote: How would you know the make program that the user will actually use? Assume it is either the default one, or that $MAKE is passed to configure. Automake-generated configure code has been doing this assumption since a long time, so nothing new here

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

Hi Bob, thanks for the prompt feedback. On 01/03/2013 08:14 PM, Bob Friesenhahn wrote: > On Thu, 3 Jan 2013, Stefano Lattarini wrote: >> >> The known make implementations that does not support recursive variable >> expansion -- as in $(foo_$(bar)) -- should by today be either very old >> or very "

bug#13324: Improvements to "dist" targets

On 01/02/2013 07:51 PM, Peter Rosin wrote: > > Yes, I believe quite a few projects have a separately maintained Visual > Studio solution, seeded with handwritten config.h etc, meaning that they > don't require Autotools to build from source on Windows. > Right, I didn't think about that possibility

bug#13324: Improvements to "dist" targets (was: Re: EXTRA_DIST, directories, tar --exclude-vcs)

On 01/03/2013 01:57 AM, Karl Berry wrote: > OTOH, what about distribution "tarballs" in '.zip' format? They don't > use tar at all ... Time to deprecate them maybe? Is anybody actually > using them? And while at it, what about the even more obscure 'shar' > format? > > FWIW, I

bug#13324: Improvements to "dist" targets (was: Re: EXTRA_DIST, directories, tar --exclude-vcs)

On 01/03/2013 01:57 AM, Karl Berry wrote: > > that every tar (except maybe really ancient ones, can't remember, but we > > don't care) supports the -style. > > It would be nice to verify this claim on as much systems as possible > > Certainly POSIX has always required supporting -option