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@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org