Received: (at 13349) by debbugs.gnu.org; 4 Jan 2013 00:17:38 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 03 19:17:38 2013 Received: from localhost ([127.0.0.1]:42224 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1Tquyf-0006Ym-KJ for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 19:17:38 -0500 Received: from mail-ee0-f53.google.com ([74.125.83.53]:62126) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <stefano.lattarini@HIDDEN>) id 1Tquyc-0006Yf-K1 for 13349 <at> debbugs.gnu.org; Thu, 03 Jan 2013 19:17:36 -0500 Received: by mail-ee0-f53.google.com with SMTP id c50so7644021eek.12 for <13349 <at> debbugs.gnu.org>; Thu, 03 Jan 2013 16:17:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=OPPrb0t2tJVkzwcgnxbt2CWBjqXwvxTh/fhDP+x+EqE=; b=jpqIRz3nb1GtPnqkS4oP1Djf1vdnZplEQoCFpbN4zdNcEGEaWHtIxMytyqa9cRq//j YlWS1/VFvROwr48lWhHP3/2Ypc9EMUna3JbE7uDMU2FwKHONmI0c3GeP8i+W5WWWgUgP Atj+FIfDku4j32MBAUeFH7RCO2p6GURWyTKfISy8ouuR7hFVbgW+UzAWjmLE+Q5KyCv2 a96du7nJfNIHyxWbbDjBCtdttIEkfj1r05Ss7not4B7vjggomtKzCp3FZ29bAEpnGThp 6+QnP6PTyohlGOSjtSishFN2O8i3YGkAJeGYnTsuh+S3RJzB0oWC4PMdALIj8pFj6fxx cQcw== X-Received: by 10.14.203.2 with SMTP id e2mr137857646eeo.20.1357258650142; Thu, 03 Jan 2013 16:17:30 -0800 (PST) Received: from [192.168.178.21] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id v46sm107185678eep.1.2013.01.03.16.17.28 (version=SSLv3 cipher=OTHER); Thu, 03 Jan 2013 16:17:29 -0800 (PST) Message-ID: <50E61F96.2060803@HIDDEN> Date: Fri, 04 Jan 2013 01:17:26 +0100 From: Stefano Lattarini <stefano.lattarini@HIDDEN> MIME-Version: 1.0 To: Eric Blake <eblake@HIDDEN> Subject: Re: bug#13349: Re-execute with the "correct" make implementation References: <50E5D3F8.1090203@HIDDEN> <alpine.GSO.2.01.1301031305540.21849@HIDDEN> <50E5DF1C.4050800@HIDDEN> <alpine.GSO.2.01.1301031345400.21849@HIDDEN> <50E5E927.5030303@HIDDEN> <alpine.GSO.2.01.1301031428470.21849@HIDDEN> <50E5ECD7.8020902@HIDDEN> <50E5F4B4.4040604@HIDDEN> <50E5F975.3080802@HIDDEN> <50E600A9.9060508@HIDDEN> <50E614D0.5040408@HIDDEN> <50E61A2F.6010008@HIDDEN> <50E61E59.7020503@HIDDEN> In-Reply-To: <50E61E59.7020503@HIDDEN> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 13349 Cc: 13349 <at> debbugs.gnu.org, "bug-autoconf@HIDDEN" <bug-autoconf@HIDDEN>, Bob Friesenhahn <bfriesen@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -2.6 (--) [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 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. > Indeed, this is all very sensible. Yet I expounded an opposite opinion just few minutes ago. Clear indicator it's time to go to bed :-) Regards, Stefano
bug-automake@HIDDEN:bug#13349; Package automake.
Full text available.
Received: (at 13349) by debbugs.gnu.org; 4 Jan 2013 00:12:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 03 19:12:20 2013
Received: from localhost ([127.0.0.1]:42205 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1TqutX-0006PH-Hh
for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 19:12:19 -0500
Received: from mx1.redhat.com ([209.132.183.28]:39487)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <eblake@HIDDEN>) id 1TqutT-0006P5-UI
for 13349 <at> debbugs.gnu.org; Thu, 03 Jan 2013 19:12:18 -0500
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r040CAkc007492
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
Thu, 3 Jan 2013 19:12:11 -0500
Received: from [10.3.113.75] (ovpn-113-75.phx2.redhat.com [10.3.113.75])
by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
id r040CAJW007504; Thu, 3 Jan 2013 19:12:10 -0500
Message-ID: <50E61E59.7020503@HIDDEN>
Date: Thu, 03 Jan 2013 17:12:09 -0700
From: Eric Blake <eblake@HIDDEN>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Stefano Lattarini <stefano.lattarini@HIDDEN>
Subject: Re: Re-execute with the "correct" make implementation
References: <50E5D3F8.1090203@HIDDEN>
<alpine.GSO.2.01.1301031305540.21849@HIDDEN>
<50E5DF1C.4050800@HIDDEN>
<alpine.GSO.2.01.1301031345400.21849@HIDDEN>
<50E5E927.5030303@HIDDEN>
<alpine.GSO.2.01.1301031428470.21849@HIDDEN>
<50E5ECD7.8020902@HIDDEN> <50E5F4B4.4040604@HIDDEN>
<50E5F975.3080802@HIDDEN> <50E600A9.9060508@HIDDEN>
<50E614D0.5040408@HIDDEN> <50E61A2F.6010008@HIDDEN>
In-Reply-To: <50E61A2F.6010008@HIDDEN>
X-Enigmail-Version: 1.4.6
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="------------enigE40AD5BA73D2D134EA738081"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
X-Spam-Score: -6.9 (------)
X-Debbugs-Envelope-To: 13349
Cc: 13349 <at> debbugs.gnu.org, "bug-autoconf@HIDDEN" <bug-autoconf@HIDDEN>,
"automake-ng@HIDDEN" <automake-ng@HIDDEN>,
Bob Friesenhahn <bfriesen@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -6.9 (------)
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE40AD5BA73D2D134EA738081
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 ...
>=20
> 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.
>=20
>> 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.
>=20
>> +++ 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=3Dfoo=
make' 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=3D/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.
--=20
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
--------------enigE40AD5BA73D2D134EA738081
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iQEcBAEBCAAGBQJQ5h5ZAAoJEKeha0olJ0NqOoMIAIOiofXhHk4ShvIGktM3g10i
zDZWGoqyHqqDhbDFCwugj+Dc6jgfLlx6FSZ7mC7/mZJfJIoeRwiNoZYeraV0To4s
F8eJWocBw4enVhDKk3+U3bomYzHkMTDq0UNJ4zWeSM1sWD+a9/Lzgftp/CgyVg7h
kPifBMLtUB1d3w6bCVO6onhRpdMuZ4gBwO0J9lX+IlhOAarRrVPrf/gp30wwp/du
H+dO1Uh1Xq0rMPofAj4wo0B1tsmDEYR4dEwtbg7UvSefIMS65Ko+lZkGUKUgf1S+
WJHwou4zMYNN62yU9PeMNLXz4N8Jd+4nW4ExH6U99fo4lz5u2nkb2sMEGtmn854=
=CwnL
-----END PGP SIGNATURE-----
--------------enigE40AD5BA73D2D134EA738081--
bug-automake@HIDDEN:bug#13349; Package automake.
Full text available.Received: (at 13349) by debbugs.gnu.org; 4 Jan 2013 00:01:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 03 19:01:48 2013 Received: from localhost ([127.0.0.1]:42188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1TqujM-00067X-3F for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 19:01:48 -0500 Received: from mail-ee0-f52.google.com ([74.125.83.52]:56511) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <stefano.lattarini@HIDDEN>) id 1TqujJ-00067P-CT for 13349 <at> debbugs.gnu.org; Thu, 03 Jan 2013 19:01:46 -0500 Received: by mail-ee0-f52.google.com with SMTP id d17so7677709eek.39 for <13349 <at> debbugs.gnu.org>; Thu, 03 Jan 2013 16:01:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/wmH3rLh3l1yUyjAIAs28OJs1HPjIIRZxgSEwYmOOM8=; b=qJgolPVUBnOHXiNHjYleSZWFMp/kyvm89//8mN10KnvBwKeuvo/UnXhdBonxvjCAkx GuqsW7mY1/Z4Rqn/63vL9y845NHifg+LRyMnKCP6RkPSBkleTFkEW8IcG9MatL8nzPc6 rxRAgRLjfz2eJ9z94cf8z91wkWRo2AIOzpdhxjbLNjYUISFiIsgSht/hP7dhO2fCUOFq E+cHxQtq7viQKi4+XWE+8y9K0h+9KO8xfNCADsP1UC7f3b1VscsnxzqIhuHWhHKGJ6OU FCNm5YvXNtwORe1pa3cr5u5O2GIlheLpWAed96J5YKj7XZYQg1E9xC8st+MbT19Je7qM tJlg== X-Received: by 10.14.225.4 with SMTP id y4mr136578556eep.6.1357257700813; Thu, 03 Jan 2013 16:01:40 -0800 (PST) Received: from [192.168.178.21] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id f49sm107193905eep.12.2013.01.03.16.01.38 (version=SSLv3 cipher=OTHER); Thu, 03 Jan 2013 16:01:40 -0800 (PST) Message-ID: <50E61BE0.1070105@HIDDEN> Date: Fri, 04 Jan 2013 01:01:36 +0100 From: Stefano Lattarini <stefano.lattarini@HIDDEN> MIME-Version: 1.0 To: Bob Friesenhahn <bfriesen@HIDDEN> Subject: Re: bug#13349: Re-execute with the "correct" make implementation References: <50E5D3F8.1090203@HIDDEN> <alpine.GSO.2.01.1301031305540.21849@HIDDEN> <50E5DF1C.4050800@HIDDEN> <alpine.GSO.2.01.1301031345400.21849@HIDDEN> <50E5E927.5030303@HIDDEN> <alpine.GSO.2.01.1301031428470.21849@HIDDEN> <50E5ECD7.8020902@HIDDEN> <50E5F4B4.4040604@HIDDEN> <50E5F975.3080802@HIDDEN> <50E600A9.9060508@HIDDEN> <20130103225302.GA8833@HIDDEN> <50E60E3F.8050501@HIDDEN> <alpine.GSO.2.01.1301031732010.21849@HIDDEN> In-Reply-To: <alpine.GSO.2.01.1301031732010.21849@HIDDEN> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 13349 Cc: 13349 <at> debbugs.gnu.org, Nick Bowler <nbowler@HIDDEN>, "bug-autoconf@HIDDEN" <bug-autoconf@HIDDEN>, Eric Blake <eblake@HIDDEN>, "automake-ng@HIDDEN" <automake-ng@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -2.6 (--) 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: $(TARGETS) >>>> $(TARGETS): ; @gmake $(AM_MAKEFLAGS) $@ >>> >>> Unfortunately, this kind of wrapper doesn't work particularly well. If >>> the user runs something similar to: >>> >>> make -j2 all install >>> >>> then the wrapper makefile will happily fork off two independent make >>> instances in parallel: one running "gmake all" and one running "gmake >>> install". The result will probably be catastrophic. >>> >> Sigh, so very true. Adding ".NOTPARALLEL:" could fix this issue though. >> Assuming that it is portable enough ... >> >> At any case, the wrapper would be just a convenience for the most >> common cases, like: >> >> ./configure && make -j4 check && make install >> >> It doesn't have to work in all (or even most) scenarios. > > This problem (use of wrong 'make') does not impact Automake-NG at > all and it does not seem wise to create a complex solution for a > problem which is seldom encountered and typically benign. > I agree (but then, I'm biased, because I'd be the one who would have to try to implement such a complex solution ;-) But I think it's a fact that a simple "low-tech" solution like encouraging developers who require GNU make (through Automake-Ng or otherwise) to use the "GNUmakefile" name for their makefiles would probably give us 90% of the benefits with 1% of the work. Regards, Stefano
bug-automake@HIDDEN:bug#13349; Package automake.
Full text available.
Received: (at 13349) by debbugs.gnu.org; 3 Jan 2013 23:54:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 03 18:54:35 2013
Received: from localhost ([127.0.0.1]:42180 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1TqucN-0005vp-7R
for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 18:54:35 -0500
Received: from mail-ee0-f50.google.com ([74.125.83.50]:64579)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <stefano.lattarini@HIDDEN>) id 1TqucK-0005vh-LF
for 13349 <at> debbugs.gnu.org; Thu, 03 Jan 2013 18:54:33 -0500
Received: by mail-ee0-f50.google.com with SMTP id b45so8002025eek.9
for <13349 <at> debbugs.gnu.org>; Thu, 03 Jan 2013 15:54:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=x-received:message-id:date:from:mime-version:to:cc:subject
:references:in-reply-to:content-type:content-transfer-encoding;
bh=u/RI9lrJUoD+t8Qch6FEf+9PWG1a9eHScX1cERi+ZcM=;
b=QXBS3ZiT70ZXCmjquoPqHbeMukOFc6IxKoMHtKwOsTmjP46IuqU5FcDw2SPdd5I2wv
p6SXXp6MKPEv/RU4Z0MpcSEm8nLyhCyiw091VZ8hC25p7Qu+6uOi7U9YLZlliD7DpqwC
DeJgSR9yudueSpmLdJwcbxBOghfNX/mdqO5D+1pTvwl9IYPcNbwHwLtSbOrY5HdAf+Li
PHdrl4wMaArmICQrTTVttkjlkPVpXmTwmD8CppuT8H0W/Xh4sETIld5uc0MWXt6HLNEy
RDM80r0dDEiZYYPTFxuA60EJ2JbP/XUjPDaeE4aztt7BRAIP6nYpIKf3HAvOAqgXweLs
DxtQ==
X-Received: by 10.14.221.9 with SMTP id q9mr139140431eep.3.1357257267837;
Thu, 03 Jan 2013 15:54:27 -0800 (PST)
Received: from [192.168.178.21]
(host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137])
by mx.google.com with ESMTPS id d3sm107179569eeo.13.2013.01.03.15.54.25
(version=SSLv3 cipher=OTHER); Thu, 03 Jan 2013 15:54:26 -0800 (PST)
Message-ID: <50E61A2F.6010008@HIDDEN>
Date: Fri, 04 Jan 2013 00:54:23 +0100
From: Stefano Lattarini <stefano.lattarini@HIDDEN>
MIME-Version: 1.0
To: Eric Blake <eblake@HIDDEN>
Subject: Re: Re-execute with the "correct" make implementation
References: <50E5D3F8.1090203@HIDDEN>
<alpine.GSO.2.01.1301031305540.21849@HIDDEN>
<50E5DF1C.4050800@HIDDEN>
<alpine.GSO.2.01.1301031345400.21849@HIDDEN>
<50E5E927.5030303@HIDDEN>
<alpine.GSO.2.01.1301031428470.21849@HIDDEN>
<50E5ECD7.8020902@HIDDEN> <50E5F4B4.4040604@HIDDEN>
<50E5F975.3080802@HIDDEN> <50E600A9.9060508@HIDDEN>
<50E614D0.5040408@HIDDEN>
In-Reply-To: <50E614D0.5040408@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.6 (--)
X-Debbugs-Envelope-To: 13349
Cc: 13349 <at> debbugs.gnu.org, "bug-autoconf@HIDDEN" <bug-autoconf@HIDDEN>,
"automake-ng@HIDDEN" <automake-ng@HIDDEN>,
Bob Friesenhahn <bfriesen@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -2.6 (--)
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 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;
>
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 ...
> 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.
> 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
> -@code{SET_MAKE}.
> +@code{SET_MAKE}, 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)])
>
It's more of a "which program you intend to use to run Makefiles", no?
Regards,
Stefano
bug-automake@HIDDEN:bug#13349; Package automake.
Full text available.
Received: (at 13349) by debbugs.gnu.org; 3 Jan 2013 23:49:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 03 18:49:57 2013
Received: from localhost ([127.0.0.1]:42176 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1TquXr-0005oX-S3
for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 18:49:57 -0500
Received: from mail-ea0-f181.google.com ([209.85.215.181]:44590)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <stefano.lattarini@HIDDEN>) id 1TquXo-0005oO-FP
for 13349 <at> debbugs.gnu.org; Thu, 03 Jan 2013 18:49:54 -0500
Received: by mail-ea0-f181.google.com with SMTP id k14so6398072eaa.12
for <13349 <at> debbugs.gnu.org>; Thu, 03 Jan 2013 15:49:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=x-received:message-id:date:from:mime-version:to:cc:subject
:references:in-reply-to:content-type:content-transfer-encoding;
bh=aRapHp+KcQGpCkES/S8RQDWwFHI2uH8YoGLJcMRIGjI=;
b=ZySLWpD+mlaGPmDlH27u95pqKGMAqN62/5hbBrVmvRmfbEtYj5AcYyMGOvDlbmVjkO
GQm9i3xBgdZ6qRU+5Km1jr/9+VDPx6rrU0XCt8V10+OB5xyc2ZCEjPdFJXmfho2R+5ds
wLo+2bWbZZLTeyJbZYGnTCYZOqrhV/Y7vu/ua1mFF08VRCDluEPRVpj2vQYe4ual2TK3
pAuXEOmtGlsu/saI0HrTTt5tN3ukeSK926FSspvet7/BU986jEZJeiJdLCEosWaGcVLr
a10mjDSXf7P67LwGYwdrSHwKGlS0WV34lMpp3XrFD/TGu6EbWiTM0LLp1v6UaIBz4AXO
0daA==
X-Received: by 10.14.173.65 with SMTP id u41mr137590345eel.13.1357256988246;
Thu, 03 Jan 2013 15:49:48 -0800 (PST)
Received: from [192.168.178.21]
(host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137])
by mx.google.com with ESMTPS id
b49sm107249615eem.16.2013.01.03.15.49.46
(version=SSLv3 cipher=OTHER); Thu, 03 Jan 2013 15:49:47 -0800 (PST)
Message-ID: <50E61917.3080503@HIDDEN>
Date: Fri, 04 Jan 2013 00:49:43 +0100
From: Stefano Lattarini <stefano.lattarini@HIDDEN>
MIME-Version: 1.0
To: Eric Blake <eblake@HIDDEN>
Subject: Re: bug#13349: Re-execute with the "correct" make implementation
References: <50E5D3F8.1090203@HIDDEN>
<alpine.GSO.2.01.1301031305540.21849@HIDDEN>
<50E5DF1C.4050800@HIDDEN>
<alpine.GSO.2.01.1301031345400.21849@HIDDEN>
<50E5E927.5030303@HIDDEN>
<alpine.GSO.2.01.1301031428470.21849@HIDDEN>
<50E5ECD7.8020902@HIDDEN> <50E5F4B4.4040604@HIDDEN>
<50E5F975.3080802@HIDDEN> <50E600A9.9060508@HIDDEN>
<50E608F1.5020006@HIDDEN>
In-Reply-To: <50E608F1.5020006@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.6 (--)
X-Debbugs-Envelope-To: 13349
Cc: 13349 <at> debbugs.gnu.org, "automake-ng@HIDDEN" <automake-ng@HIDDEN>,
Bob Friesenhahn <bfriesen@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -2.6 (--)
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 usual 'Makefile.am'), add 'GNUmakefile' to
>> an AC_CONFIG_FILES invocation, and then hand-write a simple Makefile
>> acting as a thin wrapper:
>>
>> TARGETS = all check clean distclean dist distcheck install uninstall
>> .PHONY: $(TARGETS)
>> $(TARGETS): ; @gmake $(AM_MAKEFLAGS) $@
>
> Is that sufficient, or will it bite users that get by with 'make check'
> but then fails when they do 'make file', where 'file:' was a specific
> rule in GNUMakefile?
>
It's only meant as a convenience for the most common cases.
Actually, now that I think about it, the best (because most correct)
convenience would be to have a makefile that simply aborts with a *clear*
*explicit* message if invoked with non-GNU make. Something like this:
# Default is to bail out.
__die__:
@echo This package requires GNU make >&2; exit 1;
# Do so also for all the common targets.
all check install distcheck ... : __die__
# For Solaris make, we can die for every conceivable target.
%: __die__
# Ditto for BSD make and other implementations following POSIX.
.DEFAULT:
@echo This package requires GNU make >&2; exit 1;
I've tested the above with FreeBSD make, NetBSD make, Solaris CCS and
XPG4 make, Sun distributed make, Heirloom make, IRIX 6.5 make; it worked
in all cases.
> It's too bad we can't rely on GNU make extensions
> like $(MAKECMDGOALS) as a way to override every single target at once.
> BSD make has $(.TARGETS) as something that looks like it would do the
> same, and we might even get lucky to come up with constructs that work
> nicely in some versions of make without choking any other versions of make.
>
That sounds overkill to me, honestly. The "abort clearly if run with
non-GNU make" workaround above seems good enough; especially considering
the serious issue brought up by Nick w.r.t. "make -j" usage.
After all, the Git build system requires GNU make, while using a 'Makefile'
rather than a 'GNUmakefile' (yikes), and yet, nobody has complained about
that until today, AFAICS. So I think we are worrying too much IMVHO.
>> The super-nice developer can even turn this Makefile into a Makefile.in,
>> use '@GNU_MAKE@' rather than simply 'gmake', and (from configure) look
>> for a GNU make implementation in the system and AC_SUBST '@GNU_MAKE@' to
>> its absolute path.
>
> How much of this niceness should be done by Automake-NG itself, rather
> than making developers duplicate work?
>
I think that having an option to say "for every GNUmakefile specified
in AC_CONFIG_FILES, generate a corresponding thin-wrapper Makefile"
would be a good move. Patches in that direction will be very welcome,
once we have agreed about what such a thin wrapper should actually do
;-)
>>> In fact, is it possible to write a
>>> Makefile that compares the encoded settings of $(MAKE) set at configure
>>> time, against the current value of $(MAKE) from the current make
>>> implementation running the makefile, and which can re-execute and/or
>>> loudly abort if there is a mismatch?
>>>
>> Loudly aborting on such a mismatch would likely be possible I think, by
>> adding something like this to the footer.am:
>>
>> all check clean distclean dist distcheck install uninstall: am--no-make-mismatch
>> am--no-make-mismatch:
>> @test '$(MAKE)' = '@MAKE@' || fatal mismatch
>
> But will that always work? If there are any uses of GNU-make specific
> syntax earlier in the file, will a less powerful make have already
> choked on that earlier syntax before getting to this point, negating the
> usefulness of the sanity check?
>
Good point :-/ Albeit we wouldn't be using GNU-make specific syntax, we
might be using POSIX or "almost-portable" syntax the vendor make doesn't
grok. Well, users on such inferior systems will just have to be more
careful I guess; they had to be so until today already, so they might be
used to it ...
> I speak from personal experience of using libvirt on a BSD machine;
> libvirt has already chosen to require GNU make. So I used ./configure
> MAKE=gmake, then every so often I type 'make' instead of 'gmake' on that
> package, and get:
>
> $ make
> Error expanding embedded variable.
>
> as my reminder to use gmake. But I haven't taken time to track whether
> that error would happen from just automake code in a package that tried
> to be portable to all make, or whether it specific to the fact that
> libvirt's Makefile.am already used GNU-isms.
>
>>
>> Well, almost: currently, if the make implementation in use (as specified
>> by ${MAKE-make}) doesn't set $(MAKE) automatically, configure code generated
>> by AM_INIT_AUTOMAKE causes $(MAKE) to be explicitly defined to '@MAKE@' in
>> the generated Makefile.in (to be later subst'ed by 'config.status' in the
>> resulting Makefile). But this probably happens only with old broken make
>> implementations (and maybe configure could start simply punting when such
>> a borked make is detected?).
>
> Is it worth a probe to see how many 'make's in the wild still fail to
> set $(MAKE)?
>
I think so, yes. Albeit this is pretty low-priority (patches are always
welcome though).
>> In conclusion: if this approach can be made to work, a patch would be
>> very welcome, and could go directly into 1.13.2 (as the change would not
>> be invasive in the least, and would offer more reliable build systems).
>
> Alas, I'm busy enough with other things (such as an overdue autoconf
> release) that it probably won't be me writing such a patch.
>
Even more importantly, you have shown above that my approach cannot be
made to work ;-)
Regards,
Stefano
bug-automake@HIDDEN:bug#13349; Package automake.
Full text available.Received: (at 13349) by debbugs.gnu.org; 3 Jan 2013 23:35:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 03 18:35:29 2013 Received: from localhost ([127.0.0.1]:42169 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1TquJt-0005QT-0m for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 18:35:29 -0500 Received: from blade.simplesystems.org ([65.66.246.74]:42483) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <bfriesen@HIDDEN>) id 1TquJq-0005QK-GO for 13349 <at> debbugs.gnu.org; Thu, 03 Jan 2013 18:35:27 -0500 Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id r03NZLZJ019781; Thu, 3 Jan 2013 17:35:21 -0600 (CST) Date: Thu, 3 Jan 2013 17:35:21 -0600 (CST) From: Bob Friesenhahn <bfriesen@HIDDEN> X-X-Sender: bfriesen@HIDDEN To: Stefano Lattarini <stefano.lattarini@HIDDEN> Subject: Re: bug#13349: Re-execute with the "correct" make implementation In-Reply-To: <50E60E3F.8050501@HIDDEN> Message-ID: <alpine.GSO.2.01.1301031732010.21849@HIDDEN> References: <50E5D3F8.1090203@HIDDEN> <alpine.GSO.2.01.1301031305540.21849@HIDDEN> <50E5DF1C.4050800@HIDDEN> <alpine.GSO.2.01.1301031345400.21849@HIDDEN> <50E5E927.5030303@HIDDEN> <alpine.GSO.2.01.1301031428470.21849@HIDDEN> <50E5ECD7.8020902@HIDDEN> <50E5F4B4.4040604@HIDDEN> <50E5F975.3080802@HIDDEN> <50E600A9.9060508@HIDDEN> <20130103225302.GA8833@HIDDEN> <50E60E3F.8050501@HIDDEN> User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Thu, 03 Jan 2013 17:35:22 -0600 (CST) X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 13349 Cc: 13349 <at> debbugs.gnu.org, Nick Bowler <nbowler@HIDDEN>, "bug-autoconf@HIDDEN" <bug-autoconf@HIDDEN>, Eric Blake <eblake@HIDDEN>, "automake-ng@HIDDEN" <automake-ng@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -1.9 (-) 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, this kind of wrapper doesn't work particularly well. If >> the user runs something similar to: >> >> make -j2 all install >> >> then the wrapper makefile will happily fork off two independent make >> instances in parallel: one running "gmake all" and one running "gmake >> install". The result will probably be catastrophic. >> > Sigh, so very true. Adding ".NOTPARALLEL:" could fix this issue though. > Assuming that it is portable enough ... > > At any case, the wrapper would be just a convenience for the most > common cases, like: > > ./configure && make -j4 check && make install > > It doesn't have to work in all (or even most) scenarios. This problem (use of wrong 'make') does not impact Automake-NG at all and it does not seem wise to create a complex solution for a problem which is seldom encountered and typically benign. Bob -- Bob Friesenhahn bfriesen@HIDDEN, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
bug-automake@HIDDEN:bug#13349; Package automake.
Full text available.
Received: (at 13349) by debbugs.gnu.org; 3 Jan 2013 23:31:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 03 18:31:39 2013
Received: from localhost ([127.0.0.1]:42161 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1TquGB-0005KD-9e
for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 18:31:39 -0500
Received: from mx1.redhat.com ([209.132.183.28]:1778)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <eblake@HIDDEN>) id 1TquG6-0005K4-UE
for 13349 <at> debbugs.gnu.org; Thu, 03 Jan 2013 18:31:37 -0500
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r03NVUBL000788
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
Thu, 3 Jan 2013 18:31:30 -0500
Received: from [10.3.113.75] (ovpn-113-75.phx2.redhat.com [10.3.113.75])
by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
id r03NVS3l031629; Thu, 3 Jan 2013 18:31:29 -0500
Message-ID: <50E614D0.5040408@HIDDEN>
Date: Thu, 03 Jan 2013 16:31:28 -0700
From: Eric Blake <eblake@HIDDEN>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Stefano Lattarini <stefano.lattarini@HIDDEN>
Subject: Re: Re-execute with the "correct" make implementation
References: <50E5D3F8.1090203@HIDDEN>
<alpine.GSO.2.01.1301031305540.21849@HIDDEN>
<50E5DF1C.4050800@HIDDEN>
<alpine.GSO.2.01.1301031345400.21849@HIDDEN>
<50E5E927.5030303@HIDDEN>
<alpine.GSO.2.01.1301031428470.21849@HIDDEN>
<50E5ECD7.8020902@HIDDEN> <50E5F4B4.4040604@HIDDEN>
<50E5F975.3080802@HIDDEN> <50E600A9.9060508@HIDDEN>
In-Reply-To: <50E600A9.9060508@HIDDEN>
X-Enigmail-Version: 1.4.6
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="------------enig52FB2A23933DC42A497C50E6"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Spam-Score: -6.9 (------)
X-Debbugs-Envelope-To: 13349
Cc: 13349 <at> debbugs.gnu.org, "bug-autoconf@HIDDEN" <bug-autoconf@HIDDEN>,
"automake-ng@HIDDEN" <automake-ng@HIDDEN>,
Bob Friesenhahn <bfriesen@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -6.9 (------)
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig52FB2A23933DC42A497C50E6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 01/03/2013 03:05 PM, Stefano Lattarini wrote:
>>>>
>>> Yeah, probably AM_INIT_AUTOMAKE should enhance the configure help mes=
sage
>>> 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 becaus=
e
>> 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=3Dmake}. Calls @code{AC_SUBST} for
-@code{SET_MAKE}.
+@code{SET_MAKE}, 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=3Dfoomak=
e' 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=3D`AS_ECHO(["$[2]"]) | sed 's/+/p/g; s/[[^a-zA-Z0-9_]]/_/g'`
AC_CACHE_VAL(ac_cv_prog_make_${ac_make}_set,
--=20
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
--------------enig52FB2A23933DC42A497C50E6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iQEcBAEBCAAGBQJQ5hTQAAoJEKeha0olJ0NqbvkIAI+68yxh+3cZydBE+QF4Kz4a
cp4oxuhb6YgDHG+UT0tugXJXxBPZImEih9jRkG2dnm4M5YKuC/aPNOjaDKHaXWuj
wtLHo/X3z/jS0EquUtIqbKCrbESaeCKRzna6uz50RELzzxmd5CbUg9yS0gCQ/WBA
QlwBFjmJ+Dbw7VSwi6OMrjfKe1k3i/EcnqQvGdI3tp5lS1opYNNeLc5ed5ckXJuY
cDd03hWk6BmqsUGbfOphhrymIJMRwui3JBtmy+jkrUaKvDudzxLY2PHYHzPR9vN2
/wZUbsTN3mQR5Jk5G8JZxwcoJ+NleS1KgCEc5OaJhmnUBO3e51RUvEHhfDLUqW4=
=1cNC
-----END PGP SIGNATURE-----
--------------enig52FB2A23933DC42A497C50E6--
bug-automake@HIDDEN:bug#13349; Package automake.
Full text available.Received: (at 13349) by debbugs.gnu.org; 3 Jan 2013 23:03:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 03 18:03:42 2013 Received: from localhost ([127.0.0.1]:42137 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1Tqtp7-0004cY-Pv for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 18:03:42 -0500 Received: from mail-ea0-f172.google.com ([209.85.215.172]:65371) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <stefano.lattarini@HIDDEN>) id 1Tqtp5-0004cQ-5v for 13349 <at> debbugs.gnu.org; Thu, 03 Jan 2013 18:03:40 -0500 Received: by mail-ea0-f172.google.com with SMTP id a1so6399518eaa.17 for <13349 <at> debbugs.gnu.org>; Thu, 03 Jan 2013 15:03:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=7nq2ksO9Xnrnm2aEjne/ZdNtWZJZEwBt1NCth6n3Y/U=; b=Nkk1gMMo3Kltgnd1t8LK1/XaAJZ2n9XupqnT8SJoXGVj9maczK0jPx5sLxfa6kPWRJ TUwbBRpxUQWuXmdTpWl8PQCJc5W7/5tBUu1x+RAkZCu2a1KtQvHsykJs/3DRxcPZsBxe Q4uk3FiaTK5ajbmbNv/sNBDqEH8gxgsMtc50WxAvXBC/61jpm+i6G4di5KBsFeOs82DD 9wm+tbYRXmAc+5vAORuAyezd+7kxxJvwLKchfqsggeil8w3gMjU9iKjPEimAb3vbQTtd MQyk8sh/73HV6g8sDKIItgQ2cmg2wjPRWdgoqHTBs/GhoYRKyL1C4Wfn2FOwfze5W5Ro N2tQ== X-Received: by 10.14.178.196 with SMTP id f44mr138010522eem.14.1357254213747; Thu, 03 Jan 2013 15:03:33 -0800 (PST) Received: from [192.168.178.21] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id w3sm107144291eel.17.2013.01.03.15.03.30 (version=SSLv3 cipher=OTHER); Thu, 03 Jan 2013 15:03:32 -0800 (PST) Message-ID: <50E60E3F.8050501@HIDDEN> Date: Fri, 04 Jan 2013 00:03:27 +0100 From: Stefano Lattarini <stefano.lattarini@HIDDEN> MIME-Version: 1.0 To: Nick Bowler <nbowler@HIDDEN> Subject: Re: bug#13349: Re-execute with the "correct" make implementation References: <50E5D3F8.1090203@HIDDEN> <alpine.GSO.2.01.1301031305540.21849@HIDDEN> <50E5DF1C.4050800@HIDDEN> <alpine.GSO.2.01.1301031345400.21849@HIDDEN> <50E5E927.5030303@HIDDEN> <alpine.GSO.2.01.1301031428470.21849@HIDDEN> <50E5ECD7.8020902@HIDDEN> <50E5F4B4.4040604@HIDDEN> <50E5F975.3080802@HIDDEN> <50E600A9.9060508@HIDDEN> <20130103225302.GA8833@HIDDEN> In-Reply-To: <20130103225302.GA8833@HIDDEN> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 13349 Cc: 13349 <at> debbugs.gnu.org, "bug-autoconf@HIDDEN" <bug-autoconf@HIDDEN>, Eric Blake <eblake@HIDDEN>, "automake-ng@HIDDEN" <automake-ng@HIDDEN>, Bob Friesenhahn <bfriesen@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -2.6 (--) 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 particularly well. If > the user runs something similar to: > > make -j2 all install > > then the wrapper makefile will happily fork off two independent make > instances in parallel: one running "gmake all" and one running "gmake > install". The result will probably be catastrophic. > Sigh, so very true. Adding ".NOTPARALLEL:" could fix this issue though. Assuming that it is portable enough ... At any case, the wrapper would be just a convenience for the most common cases, like: ./configure && make -j4 check && make install It doesn't have to work in all (or even most) scenarios. Regards, Stefano
bug-automake@HIDDEN:bug#13349; Package automake.
Full text available.Received: (at 13349) by debbugs.gnu.org; 3 Jan 2013 22:53:12 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 03 17:53:12 2013 Received: from localhost ([127.0.0.1]:42132 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1Tqtew-0004Lj-W5 for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 17:53:11 -0500 Received: from mx.scalarmail.ca ([98.158.95.75]:30938 helo=ironport-01.sms.scalar.ca) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <prvs=nbowler=70892d9f3@HIDDEN>) id 1Tqteu-0004La-Ai for 13349 <at> debbugs.gnu.org; Thu, 03 Jan 2013 17:53:09 -0500 Received: from unknown (HELO sms-zimbra-mta-01.sms.scalar.ca) ([192.168.32.56]) by ironport-01.sms.scalar.ca with ESMTP; 03 Jan 2013 17:53:04 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by sms-zimbra-mta-01.sms.scalar.ca (Postfix) with ESMTP id 076B217F49; Thu, 3 Jan 2013 17:53:04 -0500 (EST) Received: from sms-zimbra-mta-01.sms.scalar.ca ([127.0.0.1]) by localhost (sms-zimbra-mta-01.sms.scalar.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcvgX-H5RMzc; Thu, 3 Jan 2013 17:53:03 -0500 (EST) Received: from mail.ellipticsemi.com (dsl-67-204-24-19.acanac.net [67.204.24.19]) (Authenticated sender: nbowler@HIDDEN) by sms-zimbra-mta-01.sms.scalar.ca (Postfix) with ESMTPSA id D37F917F48; Thu, 3 Jan 2013 17:53:02 -0500 (EST) Date: Thu, 3 Jan 2013 17:53:02 -0500 From: Nick Bowler <nbowler@HIDDEN> To: Stefano Lattarini <stefano.lattarini@HIDDEN> Subject: Re: Re-execute with the "correct" make implementation Message-ID: <20130103225302.GA8833@HIDDEN> References: <50E5D3F8.1090203@HIDDEN> <alpine.GSO.2.01.1301031305540.21849@HIDDEN> <50E5DF1C.4050800@HIDDEN> <alpine.GSO.2.01.1301031345400.21849@HIDDEN> <50E5E927.5030303@HIDDEN> <alpine.GSO.2.01.1301031428470.21849@HIDDEN> <50E5ECD7.8020902@HIDDEN> <50E5F4B4.4040604@HIDDEN> <50E5F975.3080802@HIDDEN> <50E600A9.9060508@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50E600A9.9060508@HIDDEN> Organization: Elliptic Technologies Inc. User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 13349 Cc: 13349 <at> debbugs.gnu.org, "bug-autoconf@HIDDEN" <bug-autoconf@HIDDEN>, Eric Blake <eblake@HIDDEN>, "automake-ng@HIDDEN" <automake-ng@HIDDEN>, Bob Friesenhahn <bfriesen@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -0.5 (/) 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 magic of Automake-NG is in > > GNUMakefile, so that even if the user types 'make all' they still end up > > running 'gmake all' under the hood? > > > 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_CONFIG_FILES invocation, and then hand-write a simple Makefile > acting as a thin wrapper: > > TARGETS = all check clean distclean dist distcheck install uninstall > .PHONY: $(TARGETS) > $(TARGETS): ; @gmake $(AM_MAKEFLAGS) $@ Unfortunately, this kind of wrapper doesn't work particularly well. If the user runs something similar to: make -j2 all install then the wrapper makefile will happily fork off two independent make instances in parallel: one running "gmake all" and one running "gmake install". The result will probably be catastrophic. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
bug-automake@HIDDEN:bug#13349; Package automake.
Full text available.
Received: (at 13349) by debbugs.gnu.org; 3 Jan 2013 22:41:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 03 17:41:19 2013
Received: from localhost ([127.0.0.1]:42126 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1TqtTS-000438-JB
for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 17:41:19 -0500
Received: from mx1.redhat.com ([209.132.183.28]:25893)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <eblake@HIDDEN>) id 1TqtTN-00042a-ED
for 13349 <at> debbugs.gnu.org; Thu, 03 Jan 2013 17:41:17 -0500
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r03MetVX007312
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
Thu, 3 Jan 2013 17:41:02 -0500
Received: from [10.3.113.75] (ovpn-113-75.phx2.redhat.com [10.3.113.75])
by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
id r03MenmX010517; Thu, 3 Jan 2013 17:40:54 -0500
Message-ID: <50E608F1.5020006@HIDDEN>
Date: Thu, 03 Jan 2013 15:40:49 -0700
From: Eric Blake <eblake@HIDDEN>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Stefano Lattarini <stefano.lattarini@HIDDEN>
Subject: Re: Re-execute with the "correct" make implementation
References: <50E5D3F8.1090203@HIDDEN>
<alpine.GSO.2.01.1301031305540.21849@HIDDEN>
<50E5DF1C.4050800@HIDDEN>
<alpine.GSO.2.01.1301031345400.21849@HIDDEN>
<50E5E927.5030303@HIDDEN>
<alpine.GSO.2.01.1301031428470.21849@HIDDEN>
<50E5ECD7.8020902@HIDDEN> <50E5F4B4.4040604@HIDDEN>
<50E5F975.3080802@HIDDEN> <50E600A9.9060508@HIDDEN>
In-Reply-To: <50E600A9.9060508@HIDDEN>
X-Enigmail-Version: 1.4.6
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="------------enigF97F114B64713281D7B2E5FA"
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
X-Spam-Score: -6.9 (------)
X-Debbugs-Envelope-To: 13349
Cc: 13349 <at> debbugs.gnu.org, "automake-ng@HIDDEN" <automake-ng@HIDDEN>,
Bob Friesenhahn <bfriesen@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -6.9 (------)
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF97F114B64713281D7B2E5FA
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
[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-N=
G
> input file (instead of the usual 'Makefile.am'), add 'GNUmakefile' to
> an AC_CONFIG_FILES invocation, and then hand-write a simple Makefile
> acting as a thin wrapper:
>=20
> TARGETS =3D all check clean distclean dist distcheck install uninstal=
l
> .PHONY: $(TARGETS)
> $(TARGETS): ; @gmake $(AM_MAKEFLAGS) $@
Is that sufficient, or will it bite users that get by with 'make check'
but then fails when they do 'make file', where 'file:' was a specific
rule in GNUMakefile? It's too bad we can't rely on GNU make extensions
like $(MAKECMDGOALS) as a way to override every single target at once.
BSD make has $(.TARGETS) as something that looks like it would do the
same, and we might even get lucky to come up with constructs that work
nicely in some versions of make without choking any other versions of mak=
e.
>=20
> The super-nice developer can even turn this Makefile into a Makefile.in=
,
> use '@GNU_MAKE@' rather than simply 'gmake', and (from configure) look
> for a GNU make implementation in the system and AC_SUBST '@GNU_MAKE@' t=
o
> its absolute path.
How much of this niceness should be done by Automake-NG itself, rather
than making developers duplicate work?
>=20
>> In fact, is it possible to write a
>> Makefile that compares the encoded settings of $(MAKE) set at configur=
e
>> time, against the current value of $(MAKE) from the current make
>> implementation running the makefile, and which can re-execute and/or
>> loudly abort if there is a mismatch?
>>
> Loudly aborting on such a mismatch would likely be possible I think, by=
> adding something like this to the footer.am:
>=20
> all check clean distclean dist distcheck install uninstall: am--no-=
make-mismatch
> am--no-make-mismatch:
> @test '$(MAKE)' =3D '@MAKE@' || fatal mismatch
But will that always work? If there are any uses of GNU-make specific
syntax earlier in the file, will a less powerful make have already
choked on that earlier syntax before getting to this point, negating the
usefulness of the sanity check?
I speak from personal experience of using libvirt on a BSD machine;
libvirt has already chosen to require GNU make. So I used ./configure
MAKE=3Dgmake, then every so often I type 'make' instead of 'gmake' on tha=
t
package, and get:
$ make
Error expanding embedded variable.
as my reminder to use gmake. But I haven't taken time to track whether
that error would happen from just automake code in a package that tried
to be portable to all make, or whether it specific to the fact that
libvirt's Makefile.am already used GNU-isms.
>=20
> Well, almost: currently, if the make implementation in use (as specifie=
d
> by ${MAKE-make}) doesn't set $(MAKE) automatically, configure code gene=
rated
> by AM_INIT_AUTOMAKE causes $(MAKE) to be explicitly defined to '@MAKE@'=
in
> the generated Makefile.in (to be later subst'ed by 'config.status' in t=
he
> resulting Makefile). But this probably happens only with old broken ma=
ke
> implementations (and maybe configure could start simply punting when su=
ch
> a borked make is detected?).
Is it worth a probe to see how many 'make's in the wild still fail to
set $(MAKE)?
>=20
> In conclusion: if this approach can be made to work, a patch would be
> very welcome, and could go directly into 1.13.2 (as the change would no=
t
> be invasive in the least, and would offer more reliable build systems).=
Alas, I'm busy enough with other things (such as an overdue autoconf
release) that it probably won't be me writing such a patch.
--=20
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
--------------enigF97F114B64713281D7B2E5FA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iQEcBAEBCAAGBQJQ5gjxAAoJEKeha0olJ0NqsvAIAIUHyE6StMcGA69rh/L4TWzH
qYnwaGNl7tRQqTVfzC7fCCfRR2Y/jtGNbMZAKu/cpIU3fcizP4CL/01u5MydkczC
pae0VZrhmf5il2xuoSMpMUuXYytksc0qlglpjiBc/PJOp87XNLt5nGR+JODhjXxY
WkDaimiaHakjnI6DtI810BTJVYfbWf2b5wMaw4apNc4DNrf65mTdE4xuG77rGh7d
+3DlSGAaHtwk4RDdUpqXE90feMIlrLcEUEBI8yBbQsh7hNz9NejaBCzcBzgLikQ0
wK4y/Z261Agxn1kAAY3cV4/LFxTl3i3rbM3p96VhwV2QHmoEIgB5OSC2SdqxL2U=
=58pL
-----END PGP SIGNATURE-----
--------------enigF97F114B64713281D7B2E5FA--
bug-automake@HIDDEN:bug#13349; Package automake.
Full text available.
Received: (at 13349) by debbugs.gnu.org; 3 Jan 2013 22:05:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 03 17:05:41 2013
Received: from localhost ([127.0.0.1]:42101 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1Tqsuz-00038x-0h
for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 17:05:41 -0500
Received: from mail-ee0-f48.google.com ([74.125.83.48]:47640)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <stefano.lattarini@HIDDEN>) id 1Tqsuw-00038p-DW
for 13349 <at> debbugs.gnu.org; Thu, 03 Jan 2013 17:05:40 -0500
Received: by mail-ee0-f48.google.com with SMTP id b57so7878980eek.35
for <13349 <at> debbugs.gnu.org>; Thu, 03 Jan 2013 14:05:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=x-received:message-id:date:from:mime-version:to:cc:subject
:references:in-reply-to:content-type:content-transfer-encoding;
bh=91/VubGTZt5q8En8ruudhJ6NLDYPLbImD9MmcT3g5vI=;
b=mcqLcPGkuOtmn/+4fmr8h5TeCbQkXSyZi+kq6PkHZ/tUEBmVtEZzv+j861uWcQzyef
Px+Ko9agf26cz1QHNBYxrdaT0kMZ6KdgiIhBLTmpNjf9nuwtAe38lugSygn0whA3YIgr
bzxfrpxGjRDMbtlXp30L8tRjMxwkFDpxEBwGKbRWuYSZuzWis+Cg1YmVtrzGc615re1V
hizCnCAftwvEMVw7XOwWlJD6M0d01UcB+Uo6eo+1eRt2xGANVNESCUifhC6/wyQF6lS6
dptH0g6aq3M4ebYO2pR4jotDXe7swwXA0KwRxyA4zYyoGNr+LRt6QmMDIyWmqIUn8P/J
OLGQ==
X-Received: by 10.14.176.66 with SMTP id a42mr137352136eem.34.1357250734316;
Thu, 03 Jan 2013 14:05:34 -0800 (PST)
Received: from [192.168.178.21]
(host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137])
by mx.google.com with ESMTPS id
f49sm106692522eep.12.2013.01.03.14.05.31
(version=SSLv3 cipher=OTHER); Thu, 03 Jan 2013 14:05:33 -0800 (PST)
Message-ID: <50E600A9.9060508@HIDDEN>
Date: Thu, 03 Jan 2013 23:05:29 +0100
From: Stefano Lattarini <stefano.lattarini@HIDDEN>
MIME-Version: 1.0
To: Eric Blake <eblake@HIDDEN>
Subject: Re-execute with the "correct" make implementation
References: <50E5D3F8.1090203@HIDDEN>
<alpine.GSO.2.01.1301031305540.21849@HIDDEN>
<50E5DF1C.4050800@HIDDEN>
<alpine.GSO.2.01.1301031345400.21849@HIDDEN>
<50E5E927.5030303@HIDDEN>
<alpine.GSO.2.01.1301031428470.21849@HIDDEN>
<50E5ECD7.8020902@HIDDEN> <50E5F4B4.4040604@HIDDEN>
<50E5F975.3080802@HIDDEN>
In-Reply-To: <50E5F975.3080802@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 13349
Cc: 13349 <at> debbugs.gnu.org, "bug-autoconf@HIDDEN" <bug-autoconf@HIDDEN>,
"automake-ng@HIDDEN" <automake-ng@HIDDEN>,
Bob Friesenhahn <bfriesen@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -2.6 (--)
[+cc Automake-NG]
Reference: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13349#31>
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 INSTALL?
>>>
>> Indeed, we should warn the user that if he configures an Autotools-based
>> package with MAKE set in the environment (or passed on the command line),
>> that he must use that same $MAKE to build the package; if this doesn't
>> happen, semi-random (albeit unlikely) failures can crop up.
>
> Okay, I'll whip up that autoconf patch.
>
Thanks.
>>> For that matter, should
>>> autoconf (and/or automake) mark MAKE as a precious variable, so that it
>>> gets listed in './configure --help', and so 'MAKE=gmake ./configure' has
>>> the same results as './configure MAKE=gmake'?
>>>
>> 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.
>> As for $MAKE
>> becoming a precious variable, it cannot certainly hurt, but is not truly
>> relevant either, since the user still has to invoke $MAKE himself, and
>> configure cannot help him there.
>
> 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 magic of Automake-NG is in
> GNUMakefile, so that even if the user types 'make all' they still end up
> running 'gmake all' under the hood?
>
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_CONFIG_FILES invocation, and then hand-write a simple Makefile
acting as a thin wrapper:
TARGETS = all check clean distclean dist distcheck install uninstall
.PHONY: $(TARGETS)
$(TARGETS): ; @gmake $(AM_MAKEFLAGS) $@
The super-nice developer can even turn this Makefile into a Makefile.in,
use '@GNU_MAKE@' rather than simply 'gmake', and (from configure) look
for a GNU make implementation in the system and AC_SUBST '@GNU_MAKE@' to
its absolute path.
> In fact, is it possible to write a
> Makefile that compares the encoded settings of $(MAKE) set at configure
> time, against the current value of $(MAKE) from the current make
> implementation running the makefile, and which can re-execute and/or
> loudly abort if there is a mismatch?
>
Loudly aborting on such a mismatch would likely be possible I think, by
adding something like this to the footer.am:
all check clean distclean dist distcheck install uninstall: am--no-make-mismatch
am--no-make-mismatch:
@test '$(MAKE)' = '@MAKE@' || fatal mismatch
Well, almost: currently, if the make implementation in use (as specified
by ${MAKE-make}) doesn't set $(MAKE) automatically, configure code generated
by AM_INIT_AUTOMAKE causes $(MAKE) to be explicitly defined to '@MAKE@' in
the generated Makefile.in (to be later subst'ed by 'config.status' in the
resulting Makefile). But this probably happens only with old broken make
implementations (and maybe configure could start simply punting when such
a borked make is detected?).
In conclusion: if this approach can be made to work, a patch would be
very welcome, and could go directly into 1.13.2 (as the change would not
be invasive in the least, and would offer more reliable build systems).
Thanks,
Stefano
bug-automake@HIDDEN:bug#13349; Package automake.
Full text available.Received: (at 13349) by debbugs.gnu.org; 3 Jan 2013 21:35:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 03 16:35:30 2013 Received: from localhost ([127.0.0.1]:42033 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1TqsRd-0001RT-Q9 for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 16:35:23 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55158) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <eblake@HIDDEN>) id 1TqsR9-0001Qa-4A for 13349 <at> debbugs.gnu.org; Thu, 03 Jan 2013 16:34:56 -0500 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r03LYkgd029756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Jan 2013 16:34:46 -0500 Received: from [10.3.113.75] (ovpn-113-75.phx2.redhat.com [10.3.113.75]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r03LYj2g014940; Thu, 3 Jan 2013 16:34:46 -0500 Message-ID: <50E5F975.3080802@HIDDEN> Date: Thu, 03 Jan 2013 14:34:45 -0700 From: Eric Blake <eblake@HIDDEN> Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Stefano Lattarini <stefano.lattarini@HIDDEN> Subject: Re: bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally? References: <50E5D3F8.1090203@HIDDEN> <alpine.GSO.2.01.1301031305540.21849@HIDDEN> <50E5DF1C.4050800@HIDDEN> <alpine.GSO.2.01.1301031345400.21849@HIDDEN> <50E5E927.5030303@HIDDEN> <alpine.GSO.2.01.1301031428470.21849@HIDDEN> <50E5ECD7.8020902@HIDDEN> <50E5F4B4.4040604@HIDDEN> In-Reply-To: <50E5F4B4.4040604@HIDDEN> X-Enigmail-Version: 1.4.6 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig62085DB99345BFC764094871" X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 13349 Cc: 13349 <at> debbugs.gnu.org, "bug-autoconf@HIDDEN" <bug-autoconf@HIDDEN>, Bob Friesenhahn <bfriesen@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -6.9 (------) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig62085DB99345BFC764094871 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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-base= d > package with MAKE set in the environment (or passed on the command line= ), > that he must use that same $MAKE to build the package; if this doesn't > happen, semi-random (albeit unlikely) failures can crop up. Okay, I'll whip up that autoconf patch. >=20 >> For that matter, should >> autoconf (and/or automake) mark MAKE as a precious variable, so that i= t >> gets listed in './configure --help', and so 'MAKE=3Dgmake ./configure'= has >> the same results as './configure MAKE=3Dgmake'? >> > Yeah, probably AM_INIT_AUTOMAKE should enhance the configure help messa= ge > 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). > As for $MAKE > becoming a precious variable, it cannot certainly hurt, but is not trul= y > relevant either, since the user still has to invoke $MAKE himself, and > configure cannot help him there. 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 magic of Automake-NG is in GNUMakefile, so that even if the user types 'make all' they still end up running 'gmake all' under the hood? In fact, is it possible to write a Makefile that compares the encoded settings of $(MAKE) set at configure time, against the current value of $(MAKE) from the current make implementation running the makefile, and which can re-execute and/or loudly abort if there is a mismatch? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig62085DB99345BFC764094871 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBCAAGBQJQ5fl1AAoJEKeha0olJ0Nq3UgIAJkpPNPD66nhwloakvIW6nV9 9EhMVcgzqTqY6O/MkkuQdBsm+mO2K80xQQ1vGnhMg32Yy+lVJoIkoc8/2PjT3BHB UWmkm5ZlOMt7lHN1MOYrTTDw9DUJMB+ZkaJcIywNI4xLA4zdvEw/ZsxMQ518sWec G/2apJmQXqHXcXBrfmuEfWsF9nGGrQtoI4AzBOeQ88VFlaW8GbwYlBQJpaDFmUw8 JuFn+hj2jx+6vrYK3b9cgZTinEgE/Q2aSDpBAYyv2AC64WBSTjlq+052DhPAUT2I uaj+JWll0yzcCDQk8Pu6hbgzcytmvr2shjXpaXzhZdhuiYw7quRtAU4eN4Br3J4= =Mcu1 -----END PGP SIGNATURE----- --------------enig62085DB99345BFC764094871--
bug-automake@HIDDEN:bug#13349; Package automake.
Full text available.Received: (at 13349) by debbugs.gnu.org; 3 Jan 2013 21:14:41 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 03 16:14:40 2013 Received: from localhost ([127.0.0.1]:42022 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1Tqs7c-0000wh-Ao for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 16:14:40 -0500 Received: from mail-ee0-f51.google.com ([74.125.83.51]:36288) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <stefano.lattarini@HIDDEN>) id 1Tqs7Y-0000wX-7U for 13349 <at> debbugs.gnu.org; Thu, 03 Jan 2013 16:14:37 -0500 Received: by mail-ee0-f51.google.com with SMTP id d4so7559739eek.24 for <13349 <at> debbugs.gnu.org>; Thu, 03 Jan 2013 13:14:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=WJpkSdcvungWkxuluELlHWq3fvNErvVKsCZbn9LC+mw=; b=cezYijclYglTVfs9q7SOnpOLR6yZko7mBq4v5nJkmrIQ3s++gVVUpeiz4SIGnkBu6F 3wral3P9EzSJbQ66pXwEEB2Cp8BfZwd3WILZ2kCXqW7MC0WsIPa6TEY4awCAAbHq75J/ LM/6sJTWsA9VpnkRrZYucpOpfaDG6ydCiEJOzhsRSp3oUi2vU7YoHA0vQeFeXX6GmK76 9BopHpHL77k6NNMrxuhP2/sE2mnAH0VwEyvff09HZYUWr1R6XjiiXe1QjIJ8TK/9iHPA cWGd3OC6SfwvzavPnS+rxmTKO8c+RiBjBM7/flE4k5DkIm4atv5J/PmrKGUFHr0FKemF 607g== X-Received: by 10.14.225.194 with SMTP id z42mr137611985eep.22.1357247672377; Thu, 03 Jan 2013 13:14:32 -0800 (PST) Received: from [192.168.178.21] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id l3sm106468281eem.14.2013.01.03.13.14.30 (version=SSLv3 cipher=OTHER); Thu, 03 Jan 2013 13:14:31 -0800 (PST) Message-ID: <50E5F4B4.4040604@HIDDEN> Date: Thu, 03 Jan 2013 22:14:28 +0100 From: Stefano Lattarini <stefano.lattarini@HIDDEN> MIME-Version: 1.0 To: Eric Blake <eblake@HIDDEN> Subject: Re: bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally? References: <50E5D3F8.1090203@HIDDEN> <alpine.GSO.2.01.1301031305540.21849@HIDDEN> <50E5DF1C.4050800@HIDDEN> <alpine.GSO.2.01.1301031345400.21849@HIDDEN> <50E5E927.5030303@HIDDEN> <alpine.GSO.2.01.1301031428470.21849@HIDDEN> <50E5ECD7.8020902@HIDDEN> In-Reply-To: <50E5ECD7.8020902@HIDDEN> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 13349 Cc: 13349 <at> debbugs.gnu.org, "bug-autoconf@HIDDEN" <bug-autoconf@HIDDEN>, Bob Friesenhahn <bfriesen@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -1.2 (-) 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 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 mentioned by any instructional text, >>>> users can't be expected to ever use it. >>>> >>> This makes sense? Care to attempt a patch? I'm not going to >>> do it myself, I must admit. >> >> If Automake-dependent packages are dependent on MAKE, then it seems that >> mention of MAKE should be added to the standard GNU INSTALL file (not >> just Automake's copy). >> >> Previous to use by Automake in configure scripts, MAKE was an >> environment variable used for internal communication from a parent make >> process to a subordinate make process and set by make itself. > > 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 passed on the command line), that he must use that same $MAKE to build the package; if this doesn't happen, semi-random (albeit unlikely) failures can crop up. > For that matter, should > autoconf (and/or automake) mark MAKE as a precious variable, so that it > gets listed in './configure --help', and so 'MAKE=gmake ./configure' has > the same results as './configure MAKE=gmake'? > Yeah, probably AM_INIT_AUTOMAKE should enhance the configure help message to report the "quirky" role of $MAKE (patches welcome). As for $MAKE becoming a precious variable, it cannot certainly hurt, but is not truly relevant either, since the user still has to invoke $MAKE himself, and configure cannot help him there. Regards, Stefano
bug-automake@HIDDEN:bug#13349; Package automake.
Full text available.Received: (at 13349) by debbugs.gnu.org; 3 Jan 2013 20:41:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 03 15:41:37 2013 Received: from localhost ([127.0.0.1]:42004 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1Tqrbd-00006q-6w for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 15:41:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:20051) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <eblake@HIDDEN>) id 1TqrbZ-00006f-19 for 13349 <at> debbugs.gnu.org; Thu, 03 Jan 2013 15:41:35 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r03KfSPc008787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Jan 2013 15:41:29 -0500 Received: from [10.3.113.75] (ovpn-113-75.phx2.redhat.com [10.3.113.75]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r03KeuF4010274; Thu, 3 Jan 2013 15:41:12 -0500 Message-ID: <50E5ECD7.8020902@HIDDEN> Date: Thu, 03 Jan 2013 13:40:55 -0700 From: Eric Blake <eblake@HIDDEN> Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Bob Friesenhahn <bfriesen@HIDDEN> Subject: Re: bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally? References: <50E5D3F8.1090203@HIDDEN> <alpine.GSO.2.01.1301031305540.21849@HIDDEN> <50E5DF1C.4050800@HIDDEN> <alpine.GSO.2.01.1301031345400.21849@HIDDEN> <50E5E927.5030303@HIDDEN> <alpine.GSO.2.01.1301031428470.21849@HIDDEN> In-Reply-To: <alpine.GSO.2.01.1301031428470.21849@HIDDEN> X-Enigmail-Version: 1.4.6 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigD638DC4529485B22A2325B47" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 13349 Cc: 13349 <at> debbugs.gnu.org, "bug-autoconf@HIDDEN" <bug-autoconf@HIDDEN>, Stefano Lattarini <stefano.lattarini@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -6.9 (------) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD638DC4529485B22A2325B47 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [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 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 mentioned by any instructional text, >>> users can't be expected to ever use it. >>> >> This makes sense? Care to attempt a patch? I'm not going to >> do it myself, I must admit. >=20 > If Automake-dependent packages are dependent on MAKE, then it seems tha= t > mention of MAKE should be added to the standard GNU INSTALL file (not > just Automake's copy). >=20 > Previous to use by Automake in configure scripts, MAKE was an > environment variable used for internal communication from a parent make= > process to a subordinate make process and set by make itself. So what's the verdict - do we (want to) support the user overriding MAKE, and therefore document that in INSTALL? For that matter, should autoconf (and/or automake) mark MAKE as a precious variable, so that it gets listed in './configure --help', and so 'MAKE=3Dgmake ./configure' ha= s the same results as './configure MAKE=3Dgmake'? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enigD638DC4529485B22A2325B47 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBCAAGBQJQ5ezXAAoJEKeha0olJ0NqewMIAJOF/2bxls2sKCK/iKD5j6Gw 0Od+YxNtF2g82DubeHzNFp3KSXlFHWmFeYfgBTd3XGSrYX2AWGeagz76ey1sp+as 1kYNcFDRoL6V5CAL0QrwXGljvu7NNQduQHreK9g4vT9rJwJNNMOtOSEPSqwXz86l dhF63ZrRSVk0OdhhrsEiRz5icRkxh31RuhCsV8VI1BjA+dm0DJos2lapiyfBfC4d 2y6N0XZxq0cXUy72TCoZK3YTq0GNqhqOIBFT2S7rIgXNOYwWZiRABOFDJy8/cChi RMb+0qfOqgs8Qlka3Metvmg6Ng30h4r41PQIBsGBLMascbCtRX26c6zwe4kqKjg= =hwZj -----END PGP SIGNATURE----- --------------enigD638DC4529485B22A2325B47--
bug-automake@HIDDEN:bug#13349; Package automake.
Full text available.Received: (at 13349) by debbugs.gnu.org; 3 Jan 2013 20:33:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 03 15:33:18 2013 Received: from localhost ([127.0.0.1]:41996 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1TqrTa-0008Lo-C1 for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 15:33:18 -0500 Received: from blade.simplesystems.org ([65.66.246.74]:42144) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <bfriesen@HIDDEN>) id 1TqrTX-0008Lf-Nc for 13349 <at> debbugs.gnu.org; Thu, 03 Jan 2013 15:33:17 -0500 Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id r03KXBB0019077; Thu, 3 Jan 2013 14:33:11 -0600 (CST) Date: Thu, 3 Jan 2013 14:33:11 -0600 (CST) From: Bob Friesenhahn <bfriesen@HIDDEN> X-X-Sender: bfriesen@HIDDEN To: Stefano Lattarini <stefano.lattarini@HIDDEN> Subject: Re: bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally? In-Reply-To: <50E5E927.5030303@HIDDEN> Message-ID: <alpine.GSO.2.01.1301031428470.21849@HIDDEN> References: <50E5D3F8.1090203@HIDDEN> <alpine.GSO.2.01.1301031305540.21849@HIDDEN> <50E5DF1C.4050800@HIDDEN> <alpine.GSO.2.01.1301031345400.21849@HIDDEN> <50E5E927.5030303@HIDDEN> User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Thu, 03 Jan 2013 14:33:12 -0600 (CST) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 13349 Cc: 13349 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -1.9 (-) 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 mentioned by any instructional text, >> users can't be expected to ever use it. >> > This makes sense? Care to attempt a patch? I'm not going to > do it myself, I must admit. If Automake-dependent packages are dependent on MAKE, then it seems that mention of MAKE should be added to the standard GNU INSTALL file (not just Automake's copy). Previous to use by Automake in configure scripts, MAKE was an environment variable used for internal communication from a parent make process to a subordinate make process and set by make itself. Bob -- Bob Friesenhahn bfriesen@HIDDEN, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
bug-automake@HIDDEN:bug#13349; Package automake.
Full text available.
Received: (at 13349) by debbugs.gnu.org; 3 Jan 2013 20:25:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 03 15:25:28 2013
Received: from localhost ([127.0.0.1]:41985 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1TqrLy-000885-DO
for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 15:25:27 -0500
Received: from mail-ee0-f54.google.com ([74.125.83.54]:52507)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <stefano.lattarini@HIDDEN>) id 1TqrLu-00087u-Qc
for 13349 <at> debbugs.gnu.org; Thu, 03 Jan 2013 15:25:24 -0500
Received: by mail-ee0-f54.google.com with SMTP id c13so7862435eek.41
for <13349 <at> debbugs.gnu.org>; Thu, 03 Jan 2013 12:25:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=x-received:message-id:date:from:mime-version:to:cc:subject
:references:in-reply-to:content-type:content-transfer-encoding;
bh=KAw7iB66L/9jG8d/VySyvh7lkKckuSgRMFPX46vvYho=;
b=QjioCd82Xz31uQiJ2J+rWebd+lcCuycxNXL1WFJrFluws9QpTzf1Nkc/PRwYL7V5q6
0O8r58IcLO+R+ncdf9Xdbr50TE/TNhLXE8KNOYnK+rCiGixJ3o1YAuCKesLFXSTufC89
8V93aK4fmTD5iE3mH5WVKsuOjfFKKfP9plY5kyIOCvo1pyspygvmTRCbv2w7Zyw9mpyS
Wll/V4HXqqytVp+MqP3ZtjgUCfM3Y5+JThNfYT8841IatzAkRwWJwU8SDuyY/LJWfZzD
Ra+Gdf19laD22frASTTyQoRxBeGebym4lwsLxh+iuPt2jvQqGK50wWJ4l92tByGkw0VA
C1YQ==
X-Received: by 10.14.176.66 with SMTP id a42mr136750526eem.34.1357244719001;
Thu, 03 Jan 2013 12:25:19 -0800 (PST)
Received: from [192.168.178.21]
(host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137])
by mx.google.com with ESMTPS id 46sm106102492eeg.4.2013.01.03.12.25.16
(version=SSLv3 cipher=OTHER); Thu, 03 Jan 2013 12:25:18 -0800 (PST)
Message-ID: <50E5E927.5030303@HIDDEN>
Date: Thu, 03 Jan 2013 21:25:11 +0100
From: Stefano Lattarini <stefano.lattarini@HIDDEN>
MIME-Version: 1.0
To: Bob Friesenhahn <bfriesen@HIDDEN>
Subject: Re: bug#13349: [IMPORTANT] Could we just assuming support for make
recursive variable expansion unconditionally?
References: <50E5D3F8.1090203@HIDDEN>
<alpine.GSO.2.01.1301031305540.21849@HIDDEN>
<50E5DF1C.4050800@HIDDEN>
<alpine.GSO.2.01.1301031345400.21849@HIDDEN>
In-Reply-To: <alpine.GSO.2.01.1301031345400.21849@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Debbugs-Envelope-To: 13349
Cc: 13349 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -2.6 (--)
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 doing this
>> assumption since a long time, so nothing new here (albeit the
>> situation is clearly suboptimal).
>>
>>> Some systems may have three or four 'make' type programs installed.
>>>
>> Ah, lovely Solaris :-)
>
(About this: I was actually only joking about the confusing
/usr/ccs/bin/make vs. /usr/xpg4/bin/make "dichotomy").
> And BSD and SYSV-derived systems. GNU/Linux is about the only
> system where 'make' is almost certain to be GNU make (and maybe
> modern OS-X).
>
Of course; but then, the BSD systems are smart enough to call a
GNU make installed from ports or pkgsrc "gmake" rather than simply
"make". So, when I type "make" on those system, I expect to be
invoking BSD make rather than GNU make.
As for the SYSV-derived systems, if "make" does invoke the system
make, good; otherwise, the user running ./configure has GNU make
installed as his "default" make program, so the behaviour of the
system make is irrelevant for him. If the great majority of users
of an hypothetical vendor has its "make" command pointing to GNU
make, than the behaviour of the vendor make is to be considered
irrelevant, and that make is thus obsolete/unused in practice, no
longer worth supporting.
>> Nope, no such check from us.
>>
>> * Not in configure. Here is how Automake-generated configure code
>> looks for the make program (slightly tweaked for readability):
>>
>> am_make=${MAKE-make}
>> echo -n "checking whether $am_make supports nested variables... "
>> if ${am_cv_make_support_nested_variables+:} false; then :
>> echo -n "(cached) " >&6
>> else
>
> It seems like the above should be changed to produce an error
>
No, because if the feature is not supported, a workaround kicks in
(with graceful degradation: if nested variables cannot be used, the
make verbosity can only be set at configure runtime, rather than
also overridden at make runtime).
> and request that the user specify MAKE if support for this feature
> is important.
>
ATM, it's not really important. It will become if we proceed with
my proposal, of course.
>> That's why I proposed, in my second point (which you have elided,
>> apparently) a runtime probe to be added to *every* configure script
>> generated from a AM_INIT_AUTOMAKE-using configure.ac:
>>
>> - Enhance the checks in the AM_SILENT_RULES macro to print a loud
>> message at configure runtime if the make implementation on the
>> system isn't able to grasp recursive variable expansion, telling
>> the user to report the situation to our upstream (bug-automake).
>> This is of paramount importance for us to know how the situation
>> "in the wild" really is. In the past, Autoconf did something
>> similar to ensure the presence of shell functions in all the
>> shells worth supporting.
>
> Most users ignore configure output unless configure fails.
>
So, adjusting the roadmap:
- a loud warning in Automake 1.13.2
- an error in Automake 1.13.3, with a new temporary configure
option (or environment variable?) to make it non-fatal.
- same roadmap as before from Automake 1.14 onward.
Or even, skip the "loud warning" step and go immediately, right away
in 1.13.2, with a "fatal error that has to be explicitly quelled".
>>> If GNU make is installed on the system and called 'gmake' but
>>> the user types 'make' and 'make' does not support recursive
>>> variable expansion, what will happen?
>>>
>> Nothing, since configure does not look for gmake, but only for
>> ${MAKE-make}. If the user exports "MAKE=gmake" and then runs
>> "make", well, he's asking for troubles -- and he'll get them.
>>
>> Hope that clarifies the matter a little.
>
> 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 mentioned by any instructional text,
> users can't be expected to ever use it.
>
This makes sense? Care to attempt a patch? I'm not going to
do it myself, I must admit.
Thanks.
Stefano
bug-automake@HIDDEN:bug#13349; Package automake.
Full text available.
Received: (at submit) by debbugs.gnu.org; 3 Jan 2013 19:56:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 03 14:56:50 2013
Received: from localhost ([127.0.0.1]:41961 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1TqquH-0006Vk-S4
for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 14:56:50 -0500
Received: from eggs.gnu.org ([208.118.235.92]:41160)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <bfriesen@HIDDEN>) id 1TqquE-0006Vb-6e
for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 14:56:48 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <bfriesen@HIDDEN>) id 1TqquA-0000Xn-7s
for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 14:56:43 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level:
X-Spam-Status: No, score=-101.9 required=5.0 tests=BAYES_00, USER_IN_WHITELIST
autolearn=unavailable version=3.3.2
Received: from lists.gnu.org ([208.118.235.17]:56588)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from <bfriesen@HIDDEN>) id 1TqquA-0000Xj-51
for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 14:56:42 -0500
Received: from eggs.gnu.org ([208.118.235.92]:52521)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from <bfriesen@HIDDEN>) id 1Tqqu8-0006F8-1n
for bug-automake@HIDDEN; Thu, 03 Jan 2013 14:56:42 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <bfriesen@HIDDEN>) id 1Tqqu6-0000XE-P9
for bug-automake@HIDDEN; Thu, 03 Jan 2013 14:56:39 -0500
Received: from blade.simplesystems.org ([65.66.246.74]:42062)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from <bfriesen@HIDDEN>) id 1Tqqu6-0000XA-98
for bug-automake@HIDDEN; Thu, 03 Jan 2013 14:56:38 -0500
Received: from freddy.simplesystems.org (freddy.simplesystems.org
[65.66.246.65])
by blade.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id
r03JuZMA018370; Thu, 3 Jan 2013 13:56:35 -0600 (CST)
Date: Thu, 3 Jan 2013 13:56:35 -0600 (CST)
From: Bob Friesenhahn <bfriesen@HIDDEN>
X-X-Sender: bfriesen@HIDDEN
To: Stefano Lattarini <stefano.lattarini@HIDDEN>
Subject: Re: [IMPORTANT] Could we just assuming support for make recursive
variable expansion unconditionally?
In-Reply-To: <50E5DF1C.4050800@HIDDEN>
Message-ID: <alpine.GSO.2.01.1301031345400.21849@HIDDEN>
References: <50E5D3F8.1090203@HIDDEN>
<alpine.GSO.2.01.1301031305540.21849@HIDDEN>
<50E5DF1C.4050800@HIDDEN>
User-Agent: Alpine 2.01 (GSO 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2
(blade.simplesystems.org [65.66.246.90]);
Thu, 03 Jan 2013 13:56:36 -0600 (CST)
X-detected-operating-system: by eggs.gnu.org: Solaris 10
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 208.118.235.17
X-Spam-Score: -6.9 (------)
X-Debbugs-Envelope-To: submit
Cc: bug-automake@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -6.9 (------)
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 (albeit the
> situation is clearly suboptimal).
>
>> Some systems may have three or four 'make' type programs installed.
>>
> Ah, lovely Solaris :-)
And BSD and SYSV-derived systems. GNU/Linux is about the only system
where 'make' is almost certain to be GNU make (and maybe modern OS-X).
> Nope, no such check from us.
>
> * Not in configure. Here is how Automake-generated configure code
> looks for the make program (slightly tweaked for readability):
>
> am_make=${MAKE-make}
> echo -n "checking whether $am_make supports nested variables... "
> if ${am_cv_make_support_nested_variables+:} false; then :
> echo -n "(cached) " >&6
> else
It seems like the above should be changed to produce an error and
request that the user specify MAKE if support for this feature is
important.
> That's why I proposed, in my second point (which you have elided,
> apparently) a runtime probe to be added to *every* configure script
> generated from a AM_INIT_AUTOMAKE-using configure.ac:
>
> - Enhance the checks in the AM_SILENT_RULES macro to print a loud
> message at configure runtime if the make implementation on the
> system isn't able to grasp recursive variable expansion, telling
> the user to report the situation to our upstream (bug-automake).
> This is of paramount importance for us to know how the situation
> "in the wild" really is. In the past, Autoconf did something
> similar to ensure the presence of shell functions in all the
> shells worth supporting.
Most users ignore configure output unless configure fails.
>> If GNU make is installed on the system and called 'gmake' but
>> the user types 'make' and 'make' does not support recursive
>> variable expansion, what will happen?
>>
> Nothing, since configure does not look for gmake, but only for
> ${MAKE-make}. If the user exports "MAKE=gmake" and then runs
> "make", well, he's asking for troubles -- and he'll get them.
>
> Hope that clarifies the matter a little.
It is a problem that MAKE is not mentioned in the standard GNU INSTALL
file, or in Automake's own INSTALL file. If this variable was never
mentioned by any instructional text, users can't be expected to ever
use it.
Bob
--
Bob Friesenhahn
bfriesen@HIDDEN, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
bug-automake@HIDDEN:bug#13349; Package automake.
Full text available.
Received: (at submit) by debbugs.gnu.org; 3 Jan 2013 19:42:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 03 14:42:40 2013
Received: from localhost ([127.0.0.1]:41946 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1Tqqga-000672-4u
for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 14:42:40 -0500
Received: from eggs.gnu.org ([208.118.235.92]:38661)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <stefano.lattarini@HIDDEN>) id 1TqqgU-00066r-SL
for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 14:42:36 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <stefano.lattarini@HIDDEN>) id 1TqqgQ-0005EG-08
for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 14:42:32 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level:
X-Spam-Status: No, score=-102.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
RCVD_IN_DNSWL_LOW, T_DKIM_INVALID,
USER_IN_WHITELIST autolearn=unavailable version=3.3.2
Received: from lists.gnu.org ([208.118.235.17]:48873)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from <stefano.lattarini@HIDDEN>) id 1TqqgP-0005EB-HV
for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 14:42:29 -0500
Received: from eggs.gnu.org ([208.118.235.92]:50011)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from <stefano.lattarini@HIDDEN>) id 1TqqgO-0000f1-9A
for bug-automake@HIDDEN; Thu, 03 Jan 2013 14:42:29 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <stefano.lattarini@HIDDEN>) id 1TqqgM-0005Dc-O8
for bug-automake@HIDDEN; Thu, 03 Jan 2013 14:42:28 -0500
Received: from mail-bk0-f51.google.com ([209.85.214.51]:40899)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from <stefano.lattarini@HIDDEN>) id 1TqqgM-0005DU-D2
for bug-automake@HIDDEN; Thu, 03 Jan 2013 14:42:26 -0500
Received: by mail-bk0-f51.google.com with SMTP id ik5so6939070bkc.38
for <bug-automake@HIDDEN>; Thu, 03 Jan 2013 11:42:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=x-received:message-id:date:from:mime-version:to:cc:subject
:references:in-reply-to:content-type:content-transfer-encoding;
bh=PxHpYWPYM2XkL1CvkTPwqCDnPmGFnKUsBdl9Rgz26hw=;
b=0g1YFFGtV0nHPLR7i9s3bxkSysjtBbhECHePtvyRwstJipSLpyCEuDd36d7gtpX2Wf
tG7FSe6y4rB9Jf0Jihn3hjlxc6t0et7zDo2t6FttVv3BAqH4Otr/v+sqCxYYr2PIMNDl
RIU8RIC3QYBmzJLTxN4xeH3LrVXxwzVf+u2Y8Lfln0ovIG4x1Qp6kJvnaKoLtJu50yKz
jedC9dlQkNQ3lcW/Oi6Gwlh8RZNPYwDztfUgamLR3303GVmQuNp8uT+NySvegoypLUjN
n0tSATnqKFBPS2CcFzg0iVmILZtZJglEJb8dJ+s2ZykZTSbGail6qXx8uV3p5R2UFsRg
JzUw==
X-Received: by 10.204.147.78 with SMTP id k14mr24152744bkv.7.1357242145306;
Thu, 03 Jan 2013 11:42:25 -0800 (PST)
Received: from [192.168.178.21]
(host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137])
by mx.google.com with ESMTPS id q22sm35165452bkv.16.2013.01.03.11.42.22
(version=SSLv3 cipher=OTHER); Thu, 03 Jan 2013 11:42:24 -0800 (PST)
Message-ID: <50E5DF1C.4050800@HIDDEN>
Date: Thu, 03 Jan 2013 20:42:20 +0100
From: Stefano Lattarini <stefano.lattarini@HIDDEN>
MIME-Version: 1.0
To: Bob Friesenhahn <bfriesen@HIDDEN>
Subject: Re: [IMPORTANT] Could we just assuming support for make recursive
variable expansion unconditionally?
References: <50E5D3F8.1090203@HIDDEN>
<alpine.GSO.2.01.1301031305540.21849@HIDDEN>
In-Reply-To: <alpine.GSO.2.01.1301031305540.21849@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy]
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 208.118.235.17
X-Spam-Score: -3.4 (---)
X-Debbugs-Envelope-To: submit
Cc: bug-automake@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -6.1 (------)
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 "fringe"; so it would be nice if, starting from Automake 1.14,
>> we could begin assuming unconditionally that this feature is supported.
>
> This would be nice.
>
>> Users of those old-and-poor make implementations can still download
>> and install GNU make (which, as we all know, doesn't require a
>> pre-existing make installation to be bootstrappped).
>>
>> This change would simplify our codebase a little, would reduce the
>> number of configure-time checks for the client packages (eventually,
>> at first we should still check for our intended feature, and bail
>> out loudly and with a clear error message if that is not working),
>> and also reduce the differences between mainline Automake an
>> Automake-NG.
>
> 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 (albeit the
situation is clearly suboptimal).
> Some systems may have three or four 'make' type programs installed.
>
Ah, lovely Solaris :-)
>> So, here is the tentative roadmap:
>>
>> * Automake 1.13.2
>>
>> - Add a 'spy-make-recurs-var.sh' test verifying that the make
>> implementation used in the testsuite truly support recursive
>> variable expansion..
>
> I suspect that there is a configure check to find the most
> 'worthy' make program on the system (e.g. GNU make).
>
Nope, no such check from us.
* Not in configure. Here is how Automake-generated configure code
looks for the make program (slightly tweaked for readability):
am_make=${MAKE-make}
echo -n "checking whether $am_make supports nested variables... "
if ${am_cv_make_support_nested_variables+:} false; then :
echo -n "(cached) " >&6
else
...
* Especially not in the testsuite. In fact, to enhance coverage,
we even go to some length to ensure non-GNU tools are preferred
to the GNU ones! There even is this comment in Automake's own
'configure.ac', in the section looking for tools and programs
to be used in the testsuite:
# Prefer generic compilers to GNU ones when possible. This will
# ensure more testsuite coverage "in the wild".
# Note that we don't look for the MSVC C/C++ compiler here. This
# is deliberate; for more discussion and rationale, see:
# <http://lists.gnu.org/archive/html/automake-patches/2012-01/msg00130.html>
AC_MSG_NOTICE([will now look for generic compilers])
> This search for, and use, of the most worthy make program may foil
> this approach to detect broken make programs.
>
No such problem, in light of the above.
> Also, many/most people who install Automake from sources likely
> don't execute the test suite, especially on older slow systems
>
That's why I proposed, in my second point (which you have elided,
apparently) a runtime probe to be added to *every* configure script
generated from a AM_INIT_AUTOMAKE-using configure.ac:
- Enhance the checks in the AM_SILENT_RULES macro to print a loud
message at configure runtime if the make implementation on the
system isn't able to grasp recursive variable expansion, telling
the user to report the situation to our upstream (bug-automake).
This is of paramount importance for us to know how the situation
"in the wild" really is. In the past, Autoconf did something
similar to ensure the presence of shell functions in all the
shells worth supporting.
> If GNU make is installed on the system and called 'gmake' but
> the user types 'make' and 'make' does not support recursive
> variable expansion, what will happen?
>
Nothing, since configure does not look for gmake, but only for
${MAKE-make}. If the user exports "MAKE=gmake" and then runs
"make", well, he's asking for troubles -- and he'll get them.
Hope that clarifies the matter a little.
Thanks,
Stefano
bug-automake@HIDDEN:bug#13349; Package automake.
Full text available.Received: (at submit) by debbugs.gnu.org; 3 Jan 2013 19:14:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 03 14:14:20 2013 Received: from localhost ([127.0.0.1]:41930 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1TqqF9-0005MC-Ah for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 14:14:19 -0500 Received: from eggs.gnu.org ([208.118.235.92]:33753) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from <bfriesen@HIDDEN>) id 1TqqF6-0005Lz-H7 for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 14:14:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <bfriesen@HIDDEN>) id 1TqqF2-0004xl-AU for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 14:14:13 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-101.9 required=5.0 tests=BAYES_00, USER_IN_WHITELIST autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:44524) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <bfriesen@HIDDEN>) id 1TqqF2-0004xf-5g for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 14:14:12 -0500 Received: from eggs.gnu.org ([208.118.235.92]:45090) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <bfriesen@HIDDEN>) id 1TqqF0-0003wk-7L for bug-automake@HIDDEN; Thu, 03 Jan 2013 14:14:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <bfriesen@HIDDEN>) id 1TqqEy-0004wN-RI for bug-automake@HIDDEN; Thu, 03 Jan 2013 14:14:10 -0500 Received: from blade.simplesystems.org ([65.66.246.74]:41997) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <bfriesen@HIDDEN>) id 1TqqEy-0004uR-Jh for bug-automake@HIDDEN; Thu, 03 Jan 2013 14:14:08 -0500 Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id r03JE0Dp018241; Thu, 3 Jan 2013 13:14:00 -0600 (CST) Date: Thu, 3 Jan 2013 13:14:00 -0600 (CST) From: Bob Friesenhahn <bfriesen@HIDDEN> X-X-Sender: bfriesen@HIDDEN To: Stefano Lattarini <stefano.lattarini@HIDDEN> Subject: Re: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally? In-Reply-To: <50E5D3F8.1090203@HIDDEN> Message-ID: <alpine.GSO.2.01.1301031305540.21849@HIDDEN> References: <50E5D3F8.1090203@HIDDEN> User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Thu, 03 Jan 2013 13:14:00 -0600 (CST) X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: submit Cc: bug-automake@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -6.9 (------) 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 "fringe"; so it would be nice if, starting from Automake 1.14, > we could begin assuming unconditionally that this feature is supported. This would be nice. > Users of those old-and-poor make implementations can still download > and install GNU make (which, as we all know, doesn't require a > pre-existing make installation to be bootstrappped). > > This change would simplify our codebase a little, would reduce the > number of configure-time checks for the client packages (eventually, > at first we should still check for our intended feature, and bail > out loudly and with a clear error message if that is not working), > and also reduce the differences between mainline Automake an > Automake-NG. How would you know the make program that the user will actually use? Some systems may have three or four 'make' type programs installed. > So, here is the tentative roadmap: > > * Automake 1.13.2 > > - Add a 'spy-make-recurs-var.sh' test verifying that the make > implementation used in the testsuite truly support recursive > variable expansion.. I suspect that there is a configure check to find the most 'worthy' make program on the system (e.g. GNU make). This search for, and use, of the most worthy make program may foil this approach to detect broken make programs. Also, many/most people who install Automake from sources likely don't execute the test suite, especially on older slow systems (the ones most likely to have the problem) where the test suite would take over a day to execute. If GNU make is installed on the system and called 'gmake' but the user types 'make' and 'make' does not support recursive variable expansion, what will happen? Bob -- Bob Friesenhahn bfriesen@HIDDEN, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
bug-automake@HIDDEN:bug#13349; Package automake.
Full text available.Stefano Lattarini <stefano.lattarini@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.
Received: (at submit) by debbugs.gnu.org; 3 Jan 2013 18:55:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 03 13:55:15 2013
Received: from localhost ([127.0.0.1]:41916 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1Tqpwf-0003tK-Vh
for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 13:55:14 -0500
Received: from eggs.gnu.org ([208.118.235.92]:58756)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <stefano.lattarini@HIDDEN>) id 1Tqpwc-0003tC-Ht
for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 13:55:12 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <stefano.lattarini@HIDDEN>) id 1TqpwZ-0007tF-52
for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 13:55:08 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level:
X-Spam-Status: No, score=-102.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
RCVD_IN_DNSWL_LOW, T_DKIM_INVALID,
USER_IN_WHITELIST autolearn=unavailable version=3.3.2
Received: from lists.gnu.org ([208.118.235.17]:56771)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from <stefano.lattarini@HIDDEN>) id 1TqpwZ-0007sm-2U
for submit <at> debbugs.gnu.org; Thu, 03 Jan 2013 13:55:07 -0500
Received: from eggs.gnu.org ([208.118.235.92]:41873)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from <stefano.lattarini@HIDDEN>) id 1TqpwX-0001oB-SB
for bug-automake@HIDDEN; Thu, 03 Jan 2013 13:55:07 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <stefano.lattarini@HIDDEN>) id 1TqpwW-0007jX-BV
for bug-automake@HIDDEN; Thu, 03 Jan 2013 13:55:05 -0500
Received: from mail-bk0-f42.google.com ([209.85.214.42]:57286)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from <stefano.lattarini@HIDDEN>)
id 1TqpwW-0007hQ-3c; Thu, 03 Jan 2013 13:55:04 -0500
Received: by mail-bk0-f42.google.com with SMTP id ji2so6892338bkc.1
for <multiple recipients>; Thu, 03 Jan 2013 10:55:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=x-received:message-id:date:from:mime-version:to:subject
:content-type:content-transfer-encoding;
bh=umo1r8yYNGP86nY/eA5wzNGg/FrS7MYmoqcldWtweDU=;
b=rZiC8RDVHesTWH1bHRmNxZkY5hVSp5GW/ZEWp7SPI1n0XLtixJVouJ24hk24SlwGSl
9bwmFVMeCBkNtiUb16ajS3vN8j4B7UwhCb5oCJZwDXqIn+dQ56fcebcMWBQ/hzyMzZoJ
RqV6rFuHzX5o+5oqarbZqqrtEMnEsLO/0xYDkhRUAmJjwLJ2wCsDXfQalLTvfBur57As
HMS7sVwggXZWVA+k8JzCu3i+XS6ofdKPXSggLbwaVJnBTR0AkkEupX4aypSgymv7QRRj
YHr0qImZhzE4R9RS55qKWyCXBnhpeC8NFfhyQLK2nNUPVqrMJ3CW8pGfjo/DBrPSMc7m
Cpug==
X-Received: by 10.204.148.22 with SMTP id n22mr24853965bkv.6.1357239302925;
Thu, 03 Jan 2013 10:55:02 -0800 (PST)
Received: from [192.168.178.21]
(host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137])
by mx.google.com with ESMTPS id o7sm34975886bkv.13.2013.01.03.10.55.00
(version=SSLv3 cipher=OTHER); Thu, 03 Jan 2013 10:55:02 -0800 (PST)
Message-ID: <50E5D3F8.1090203@HIDDEN>
Date: Thu, 03 Jan 2013 19:54:48 +0100
From: Stefano Lattarini <stefano.lattarini@HIDDEN>
MIME-Version: 1.0
To: bug-automake@HIDDEN
Subject: [IMPORTANT] Could we just assuming support for make recursive variable
expansion unconditionally?
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy]
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 208.118.235.17
X-Spam-Score: -3.4 (---)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -3.4 (---)
Severity: wishlist
[This is posted also to the automake list to ensure a wider audience.
Discussion should continue exclusively on the bug-automake list.]
The known make implementations that does not support recursive variable
expansion -- as in $(foo_$(bar)) -- should by today be either very old
or very "fringe"; so it would be nice if, starting from Automake 1.14,
we could begin assuming unconditionally that this feature is supported.
Users of those old-and-poor make implementations can still download
and install GNU make (which, as we all know, doesn't require a
pre-existing make installation to be bootstrappped).
This change would simplify our codebase a little, would reduce the
number of configure-time checks for the client packages (eventually,
at first we should still check for our intended feature, and bail
out loudly and with a clear error message if that is not working),
and also reduce the differences between mainline Automake an
Automake-NG.
Of course, we should first ensure that our estimate on how support for
recursive make variable expansion is effectively widespread is correct.
So, here is the tentative roadmap:
* Automake 1.13.2
- Add a 'spy-make-recurs-var.sh' test verifying that the make
implementation used in the testsuite truly support recursive
variable expansion..
- Enhance the checks in the AM_SILENT_RULES macro to print a loud
message at configure runtime if the make implementation on the
system isn't able to grasp recursive variable expansion, telling
the user to report the situation to our upstream (bug-automake).
This is of paramount importance for us to know how the situation
"in the wild" really is. In the past, Autoconf did something
similar to ensure the presence of shell functions in all the
shells worth supporting.
* Automake 1.14 (assuming no relevant complaints has been received in
the previous "probing" step).
- Just assume, throughout our codebase, that '$(foo_$(var))' works.
Related simplifications and refactorings.
- Have AM_SILENT_RULES abort configure with a fatal error if the
make implementation on the system isn't able to grasp recursive
variable expansion.
- Make the 'portability-recursive' warnings a no-op, and have their
use print a warning in either the 'obsolete' and 'unsupported'
category.
* Automake 1.15
- Remove all the runtime checks from AM_SILENT_RULES; the only role
of this macro will at this point be the ability to set the
default verbosity, and to implement the '--enable-silent-rules'
and '--disable-silent-rules' configure options.
- Remove the 'portability-recursive' warnings altogether.
Comments would be welcome. Patches even more so ;-) (especially for
what concerns the changes intended for 1.13.2).
Stefano Lattarini <stefano.lattarini@HIDDEN>:bug-automake@HIDDEN.
Full text available.bug-automake@HIDDEN:bug#13349; Package automake.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.