[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re-execute with the "correct" make implementation
From: |
Eric Blake |
Subject: |
Re: Re-execute with the "correct" make implementation |
Date: |
Thu, 03 Jan 2013 17:12:09 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 |
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
- Re: bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?, Eric Blake, 2013/01/03
- Re: bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?, Stefano Lattarini, 2013/01/03
- Re: bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?, Eric Blake, 2013/01/03
- Re-execute with the "correct" make implementation, Stefano Lattarini, 2013/01/03
- Re: Re-execute with the "correct" make implementation, Nick Bowler, 2013/01/03
- Re: bug#13349: Re-execute with the "correct" make implementation, Stefano Lattarini, 2013/01/03
- Re: bug#13349: Re-execute with the "correct" make implementation, Bob Friesenhahn, 2013/01/03
- Re: bug#13349: Re-execute with the "correct" make implementation, Stefano Lattarini, 2013/01/03
- Re: Re-execute with the "correct" make implementation, Eric Blake, 2013/01/03
- Re: Re-execute with the "correct" make implementation, Stefano Lattarini, 2013/01/03
- Re: Re-execute with the "correct" make implementation,
Eric Blake <=
- Re: bug#13349: Re-execute with the "correct" make implementation, Stefano Lattarini, 2013/01/03
[PATCH] docs: mention $MAKE during configure, Eric Blake, 2013/01/03