Subject: Re: bug#10237: AM_SILENT_RULES does not work with NonStop make

From: "Daniel Richard G." <[email-masked]>
Date: Wed, 07 Dec 2011 02:15:57 -0500

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. || [email-masked]
My ASCII-art .sig got a bad case of Times New Roman.