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

From: "Daniel Richard G." <[email-masked]>
Date: Tue, 06 Dec 2011 18:16:46 -0500

On Tue, 2011 Dec  6 11:48-0700, Eric Blake wrote:
>
> 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.

This would certainly be an improvement on what we have now.

> 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).

Replacing a few parens with curly-braces on all platforms is ugly, but
running an additional configure check on all platforms is nice?

What if the system has GNU Make and an old, broken make, and through
some sort of PATH confusion, the configure-time check sees the former,
and the user then invokes the latter? (Sure, the user should just use
GNU Make, but why not avoid the possibility of such breakage in the
first place?)

I don't mean to object to Paul's proposed solution in itself---it'll
work for my needs just fine---but "nicer" and "consistent" seem to hold
more sway in your reasoning here than robustness and efficiency.

(Paul: Does $({}) work on NonStop?)

--Daniel

-- 
Daniel Richard G. || [email-masked]
My ASCII-art .sig got a bad case of Times New Roman.