[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#13349: Re-execute with the "correct" make implementation
From: |
Eric Blake |
Subject: |
bug#13349: Re-execute with the "correct" make implementation |
Date: |
Thu, 03 Jan 2013 16:31:28 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 |
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 of MAKE is too closely tied to automake, and
>> that autoconf itself has no business in setting MAKE as precious, only
>> documenting in the generic INSTALL that MAKE is often important because
>> of automake).
>>
> Yes, this seems the best approach.
Then again, it is autoconf that defines AC_PROG_MAKE_SET which in turn
provides @SET_MAKE@ for substitution in Makefiles; 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?
diff --git i/doc/autoconf.texi w/doc/autoconf.texi
index bb83443..67a862d 100644
--- i/doc/autoconf.texi
+++ w/doc/autoconf.texi
@@ -2208,7 +2208,7 @@ Output
@code{$(MAKE)}, define output variable @code{SET_MAKE} to be empty.
Otherwise, define @code{SET_MAKE} to a macro definition that sets
@code{$(MAKE)}, such as @samp{MAKE=make}. Calls @code{AC_SUBST} for
address@hidden
address@hidden, and also calls @code{AC_ARG_VAR} for @code{MAKE}.
@end defmac
If you use this macro, place a line like this in each @file{Makefile.in}
diff --git i/lib/autoconf/programs.m4 w/lib/autoconf/programs.m4
index f7af8b5..b6a8f78 100644
--- i/lib/autoconf/programs.m4
+++ 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)])
+AC_MSG_CHECKING([whether ${MAKE-make} sets \$(MAKE)])
set x ${MAKE-make}
ac_make=`AS_ECHO(["$[2]"]) | sed 's/+/p/g; s/[[^a-zA-Z0-9_]]/_/g'`
AC_CACHE_VAL(ac_cv_prog_make_${ac_make}_set,
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
- bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?, (continued)
- bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?, Eric Blake, 2013/01/03
- bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?, Stefano Lattarini, 2013/01/03
- bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?, Eric Blake, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Stefano Lattarini, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Eric Blake, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Stefano Lattarini, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Nick Bowler, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Stefano Lattarini, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Bob Friesenhahn, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Stefano Lattarini, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation,
Eric Blake <=
- bug#13349: Re-execute with the "correct" make implementation, Stefano Lattarini, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Eric Blake, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Stefano Lattarini, 2013/01/03