GNU bug report logs -
#10237
AM_SILENT_RULES does not work with NonStop make
Previous Next
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 #60 received at 10237 <at> debbugs.gnu.org (full text, mbox):
On Tue, 2011 Dec 6 20:23-0700, Eric Blake wrote:
>
> Yes, use of $(${}) is specifically unspecified by POSIX 2008, and use
> of that extension means you are on unportable ground. The goal is
> that POSIX 201x will require it, and that eventually make
> implementations will catch up to POSIX, but we aren't there yet.
Are there any make implementations known to support neither $(${}) nor
$($())? NonStop remains a question mark, but given that it's a
current, shipping product, I doubt it would come up any worse than an
early-90s BSD.
> There are systems that cannot tolerate the extensions to existing
> POSIX 2008 (of which, $($()) is one such extension): at least nextStep
> and nonstop.
But support for $($()) is not strictly the same as support for nested
variables in general; the former implies the latter, but not the other
way around. NeXTSTEP can do nested variables, if only with mixed
delimiters, and NonStop may well be in the same boat.
Just from the nature of the NeXTSTEP behavior, it seems to be less a
matter of POSIX-or-not than a poorly-written parser that needs mixed
delimiters in order to get the nesting right. If someone wrote a Perl
regex to match variable dereferences, and didn't think too hard about
it, it would probably have the same behavior.
> Doing a configure-time check of make capabilities will let us write
> portable makefiles even for those systems, while using $(${}) would
> avoid the configure check, and would even work around the nextstep
> limitations, but would not necessarily work for nonstop or for POSIX
> 2008 implementations.
Agreed, but that remains a hypothetical, and a configure-time approach
would necessarily disable support for "make V=..." on some systems. I
would think you'd want at least one confirmed report of $(${}) breakage
before crossing the "V=... may not work in all instances" barrier.
That said, I can't fault a better-safe-than-sorry approach, which I
think is even the better fit philosophically for the Autotools projects.
I just wish that these very real standards/implementation qualms had
been addressed when AM_SILENT_RULES was originally developed.
--Daniel
--
Daniel Richard G. || skunk <at> iSKUNK.ORG
My ASCII-art .sig got a bad case of Times New Roman.
This bug report was last modified 13 years and 146 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.