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