GNU bug report logs - #10237
AM_SILENT_RULES does not work with NonStop make

Previous Next

Package: automake;

Reported by: Paul Eggert <eggert <at> cs.ucla.edu>

Date: Tue, 6 Dec 2011 17:53:02 UTC

Severity: minor

Tags: patch

Done: Stefano Lattarini <stefano.lattarini <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #27 received at 10237 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Stefano Lattarini <stefano.lattarini <at> gmail.com>, 10237 <at> debbugs.gnu.org,
	skunk <at> iskunk.org
Subject: Re: bug#10237: AM_SILENT_RULES does not work with NonStop make
Date: Tue, 06 Dec 2011 11:48:25 -0700
[Message part 1 (text/plain, inline)]
On 12/06/2011 11:40 AM, Paul Eggert wrote:
> On 12/06/11 10:19, Stefano Lattarini wrote:
>> which will also very likely be in the next POSIX standard, if I'm not
>> mistaken)
> 
> Do you have a reference for that?  That would allay some of
> my concerns in this area, moving forward.

http://austingroupbugs.net/view.php?id=336

> 
>> I'm extremely reluctant to add yet more complexity to automake
> 
> I don't see this change as adding much complexity.  It should be
> pretty simple, and it shouldn't affect Automake much.  So I guess
> the question is: how much complexity is "too much"?  I don't want
> to bother to write and test a patch if it's going to be shot down
> no matter how simple it is.

Personally, I'm in favor of the idea.  It seems very simple at being
able to address the non-POSIX concern that Ralf first expressed when
silent make was introduced - it gives us a working solution on the few
platforms that don't do nested expansion with no loss in functionality
for the majority of make implementations, with the only penalty being
one more check during configure time.

> It is a bit off-putting to tell someone trying to install
> coreutils "well, you're going to have to install
> all this other GNU stuff first".  (And suppose GNU make
> starts depending on coreutils?...)  It's better to avoid these
> dependencies if it's easy, which seems to be the case here.

I can understand why, for bug 9928, we didn't go for the solution of
$(var${nested}), just for NextStep - that makes the existing code base
ugly on all platforms in the final generated Makefile.  But Paul's
solution is nicer - it isolates the ugliness to the configure check, and
the resulting Makefile is clean (either complying to old POSIX and you
can't override V=[01], or complying to the common extension and
hopefully next POSIX revision, but all with consistent syntax).

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

This bug report was last modified 13 years and 145 days ago.

Previous Next


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