GNU bug report logs - #13349
Could we just assume support for make recursive variable expansion unconditionally?

Previous Next

Full log

View this message in rfc822 format

From: Eric Blake <eblake <at> redhat.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 13349 <at> debbugs.gnu.org, "bug-autoconf <at> gnu.org" <bug-autoconf <at> gnu.org>, "automake-ng <at> gnu.org" <automake-ng <at> gnu.org>, Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
Subject: bug#13349: Re-execute with the "correct" make implementation
Date: Thu, 03 Jan 2013 17:12:09 -0700

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.