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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10237 in the body.
You can then email your comments to 10237 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: bug-automake <at> gnu.org
Cc: "Daniel Richard G." <skunk <at> iSKUNK.ORG>
Subject: AM_SILENT_RULES does not work with NonStop make
Date: Tue, 06 Dec 2011 09:51:32 -0800

If AM_SILENT_RULES is used, Automake generates Makefile.in
files with lines like this:

  AM_V_CC = $(am__v_CC_$(V))
  am__v_CC_ = $(am__v_CC_$(AM_DEFAULT_VERBOSITY))

and these are copied into Makefile unchanged.  Unfortunately, as
the Automake documentation notes, these lines do not conform to
the POSIX rules for 'make', and as a result packages like
Coreutils that use AM_SILENT_RULES won't build on machines whose
'make' implementations conform to POSIX but disagree with GNU make
in this area.  This is a problem with the current release of
Coreutils, which doesn't build on HP's NonStop OS (see Bug#10234).

The simplest fix for Coreutils is to not use AM_SILENT_RULES but
that defeats the purpose of the Automake feature.  How about the
following idea instead?  Automake could put something like the
following into Makefile.in:

  AM_V_CC = $(am__v_CC_ <at> AM_V@)
  am__v_CC_ = $(am__v_CC_ <at> AM_DEFAULT_VERBOSITY@)

and then Automake can do something like this:

    if make supports $(...$(...)); then
      AM_V='$(V)'
      AM_DEFAULT_VERBOSITY='$(AM_DEFAULT_VERBOSITY)'
    else
      AM_V=1
      AM_DEFAULT_VERBOSITY=1
    fi
    AC_SUBST([AM_V])
    AC_SUBST([AM_DEFAULT_VERBOSITY])

That way, Coreutils could continue to use AM_SILENT_RULES, and
these rules would work as usual on most hosts that use GNU
make-ish syntax in this area, but the rules wouldn't break on
hosts that support POSIX but not GNU make.

This idea should also fix Bug#9928 (in a different way from
what's proposed there), so I'll CC: its reporter.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jim Meyering <jim <at> meyering.net>
Cc: Basavaraj B <basavaraja.b <at> gmail.com>, 10234 <at> debbugs.gnu.org,
	10237 <at> debbugs.gnu.org
Subject: Re: bug#10234: Coreutils incompatibility with POSIX make
Date: Tue, 06 Dec 2011 09:59:17 -0800

On 12/06/11 09:36, Jim Meyering wrote:
> I am very reluctant to
> sacrifice the above default solely to accommodate that system.

Yes, the "make" chatter is annoying, but on the other
hand being portable is pretty important too.  It's not just
NonStop; NextStep 'make' has a similar problem, and I wouldn't
be surprised if it crops up on other (admittedly minor) targets.

I have filed a bug report against this with Automake; see
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10237>
(warning: the GNU mailing list software has turned some
"@"s into " <at> "s in that patch.)

Let's see if we can get it solved that way
-- it shouldn't be too hard, and it'd be much nicer.

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: bug-automake <at> gnu.org
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 10237 <at> debbugs.gnu.org,
	"Daniel Richard G." <skunk <at> iskunk.org>
Subject: Re: bug#10237: AM_SILENT_RULES does not work with NonStop make
Date: Tue, 6 Dec 2011 19:19:36 +0100

tags 10237 wontfix
close 10237
thanks

Hi Paul, thanks for the report.

On Tuesday 06 December 2011, Paul Eggert wrote:
> If AM_SILENT_RULES is used, Automake generates Makefile.in
> files with lines like this:
> 
>   AM_V_CC = $(am__v_CC_$(V))
>   am__v_CC_ = $(am__v_CC_$(AM_DEFAULT_VERBOSITY))
> 
> and these are copied into Makefile unchanged.  Unfortunately, as
> the Automake documentation notes, these lines do not conform to
> the POSIX rules for 'make', and as a result packages like
> Coreutils that use AM_SILENT_RULES won't build on machines whose
> 'make' implementations conform to POSIX but disagree with GNU make
> in this area.  This is a problem with the current release of
> Coreutils, which doesn't build on HP's NonStop OS (see Bug#10234).
>
> [SNIP]
>
I'm extremely reluctant to add yet more complexity to automake to
accomodate this very fringe case, especially considering the fact
that all non-museum make implementations that Automake is usually
tested with ({Free,Net,Open}BSD, Solaris CCS and XPG4, IRIX, AIX,
HP-UX, Tru64/OSF) support the nested-macro-expansion feature (which
will also very likely be in the next POSIX standard, if I'm not
mistaken).  If GNU make builds without problem on NonStop OS (which
I believe it does), then I'd simply advise the NonStop users to
install it and live happily.

Speaking more generally, I believe that the right thing to do to
avoid similar problems in the future is to amend the common INSTALL
files that comes with many GNU packages, to have it report a list of
known "broken" and/or "problematic" make implementation, telling the
user that they might not be usable to build the package and advising
him to get GNU make instead.

Give the above, I've closed this bug report.  But of course, feel
free to continue the discussion here if you have something to add.

Regards,
  Stefano

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: bug-automake <at> gnu.org, 10237 <at> debbugs.gnu.org,
	"Daniel Richard G." <skunk <at> iskunk.org>
Subject: Re: bug#10237: AM_SILENT_RULES does not work with NonStop make
Date: Tue, 06 Dec 2011 10:40:51 -0800

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.

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

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.

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

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 10237 <at> debbugs.gnu.org, skunk <at> iskunk.org
Subject: Re: bug#10237: AM_SILENT_RULES does not work with NonStop make
Date: Tue, 6 Dec 2011 20:02:32 +0100

reopen 10237
tags 10237 - wontfix
thanks

On Tuesday 06 December 2011, Eric Blake wrote:
>
> >> 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
>
OK, I think your combined opinions are enough to outweight my mine.

If you are interested in accomodating this fringe situation, I will
then accept a patch on the lines Paul has proposed (with a mandatory
testcase, otherwise it would be far too easy to regress in such a
almost-never-excercised corner case).  But note that most likely I'm
not going to write such a patch myself for the moment.

Regards,
  Stefano

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

From: "Daniel Richard G." <skunk <at> iSKUNK.ORG>
To: "Eric Blake" <eblake <at> redhat.com>, "Paul Eggert" <eggert <at> cs.ucla.edu>
Cc: Stefano Lattarini <stefano.lattarini <at> gmail.com>, 10237 <at> debbugs.gnu.org
Subject: Re: bug#10237: AM_SILENT_RULES does not work with NonStop make
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. || skunk <at> iSKUNK.ORG
My ASCII-art .sig got a bad case of Times New Roman.

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

From: Eric Blake <eblake <at> redhat.com>
To: "Daniel Richard G." <skunk <at> iSKUNK.ORG>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>,
	Stefano Lattarini <stefano.lattarini <at> gmail.com>, 10237 <at> debbugs.gnu.org
Subject: Re: bug#10237: AM_SILENT_RULES does not work with NonStop make
Date: Tue, 06 Dec 2011 16:26:43 -0700

[Message part 1 (text/plain, inline)]

On 12/06/2011 04:16 PM, Daniel Richard G. wrote:
> Replacing a few parens with curly-braces on all platforms is ugly, but
> running an additional configure check on all platforms is nice?

Yes, since we already do other configure checks for make capabilities,
and substitute that into Makefile.in when producing Makefile.  And no
one said we have to run all the checks on all the platforms - it may be
sufficient to detect multiple features on a single make probe run, at
least for GNU make, to minimize forking in the common case.

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

The user is already obligated to run the same make that was on the PATH
when they ran configure, or to run './configure MAKE=/path/to/make' to
hard-code their preference of make.  Automake already generates
Makefile.in that has substitutions that are implementation-specific; for
example, see how @SET_MAKE@, @am__include@, @am__quote@, and so forth
are hard-coded to the make implementation detected at configure time.

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

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

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: "Daniel Richard G." <skunk <at> iSKUNK.ORG>
Cc: Stefano Lattarini <stefano.lattarini <at> gmail.com>,
	Eric Blake <eblake <at> redhat.com>, 10237 <at> debbugs.gnu.org
Subject: Re: bug#10237: AM_SILENT_RULES does not work with NonStop make
Date: Tue, 06 Dec 2011 16:15:45 -0800

On 12/06/11 15:16, Daniel Richard G. wrote:
> (Paul: Does $({}) work on NonStop?)

I don't know, sorry.

I wanted a solution that worked
on any POSIX platform -- POSIX 2008 says that
$(aaa${bbb}) is just as unspecified as
$(aaa$(bbb)) is, and I wanted to play it safe.

Part of this is my experience with implementers who
code from the spec, so that their implementations'
quirks are not necessarily those of the historical
code.

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

From: "Daniel Richard G." <skunk <at> iSKUNK.ORG>
To: "Eric Blake" <eblake <at> redhat.com>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>,
	Stefano Lattarini <stefano.lattarini <at> gmail.com>, 10237 <at> debbugs.gnu.org
Subject: Re: bug#10237: AM_SILENT_RULES does not work with NonStop make
Date: Tue, 06 Dec 2011 22:10:47 -0500

On Tue, 2011 Dec  6 16:26-0700, Eric Blake wrote:
>
> Yes, since we already do other configure checks for make capabilities,
> and substitute that into Makefile.in when producing Makefile.  And no
> one said we have to run all the checks on all the platforms - it may
> be sufficient to detect multiple features on a single make probe run,
> at least for GNU make, to minimize forking in the common case.

That would help, surely. But I don't see why you would want to add yet
another moving part if there were a way to avoid it. I mean, if $({})
violated POSIX, or there were known implementations that could not
tolerate curlies, then sure. But the concerns that have been expressed
here are basically stylistic in nature, and while I don't disregard
those, I would think they're not nearly as important.

As far as I can see, this is on par with using "test $? != 0" instead of
-ne, or expr(1) instead of $((...)). Yes, it's less pretty, but it runs
on more systems than the pretty code. And isn't that what really
matters, at the end of the day?

> The user is already obligated to run the same make that was on the
> PATH when they ran configure, or to run './configure
> MAKE=/path/to/make' to hard-code their preference of make.  Automake
> already generates Makefile.in that has substitutions that are implementation-
> specific; for example, see how @SET_MAKE@, @am__include@, @am__quote@,
> and so forth are hard-coded to the make implementation detected at
> configure time.

I was vaguely aware of SET_MAKE, but I didn't know that using the same
make program as configure detected was a basic premise of the system. I
retract that critique, then.


--Daniel


-- 
Daniel Richard G. || skunk <at> iSKUNK.ORG
My ASCII-art .sig got a bad case of Times New Roman.

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

From: "Daniel Richard G." <skunk <at> iSKUNK.ORG>
To: "Paul Eggert" <eggert <at> cs.ucla.edu>
Cc: Stefano Lattarini <stefano.lattarini <at> gmail.com>,
	Eric Blake <eblake <at> redhat.com>, 10237 <at> debbugs.gnu.org
Subject: Re: bug#10237: AM_SILENT_RULES does not work with NonStop make
Date: Tue, 06 Dec 2011 22:20:11 -0500

On Tue, 2011 Dec  6 16:15-0800, Paul Eggert wrote:
> On 12/06/11 15:16, Daniel Richard G. wrote:
>
> > (Paul: Does $({}) work on NonStop?)
> 
> I don't know, sorry.
> 
> I wanted a solution that worked
> on any POSIX platform -- POSIX 2008 says that
> $(aaa${bbb}) is just as unspecified as
> $(aaa$(bbb)) is, and I wanted to play it safe.
> 
> Part of this is my experience with implementers who
> code from the spec, so that their implementations'
> quirks are not necessarily those of the historical
> code.

Unless an implementation forgets to allow curly-braces altogether,
however, I don't see why this wouldn't work. I've certainly seen
projects that use ${...} as the general convention. It would have to be
a pretty naive make implementation to not support that.

As I see it, the only real way to play it safe here, per POSIX, is to
forgo the use of nested variables altogether.


--Daniel


-- 
Daniel Richard G. || skunk <at> iSKUNK.ORG
My ASCII-art .sig got a bad case of Times New Roman.

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

From: Eric Blake <eblake <at> redhat.com>
To: "Daniel Richard G." <skunk <at> iSKUNK.ORG>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>,
	Stefano Lattarini <stefano.lattarini <at> gmail.com>, 10237 <at> debbugs.gnu.org
Subject: Re: bug#10237: AM_SILENT_RULES does not work with NonStop make
Date: Tue, 06 Dec 2011 20:23:50 -0700

[Message part 1 (text/plain, inline)]

On 12/06/2011 08:10 PM, Daniel Richard G. wrote:
> On Tue, 2011 Dec  6 16:26-0700, Eric Blake wrote:
>>
>> Yes, since we already do other configure checks for make capabilities,
>> and substitute that into Makefile.in when producing Makefile.  And no
>> one said we have to run all the checks on all the platforms - it may
>> be sufficient to detect multiple features on a single make probe run,
>> at least for GNU make, to minimize forking in the common case.
> 
> That would help, surely. But I don't see why you would want to add yet
> another moving part if there were a way to avoid it. I mean, if $({})
> violated POSIX,

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.

> or there were known implementations that could not
> tolerate curlies, then sure.

There are systems that cannot tolerate the extensions to existing POSIX
2008 (of which, $($()) is one such extension): at least nextStep and
nonstop.  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.

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

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

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

From: Eric Blake <eblake <at> redhat.com>
To: "Daniel Richard G." <skunk <at> iSKUNK.ORG>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>,
	Stefano Lattarini <stefano.lattarini <at> gmail.com>, 10237 <at> debbugs.gnu.org
Subject: Re: bug#10237: AM_SILENT_RULES does not work with NonStop make
Date: Tue, 06 Dec 2011 20:33:22 -0700

[Message part 1 (text/plain, inline)]

On 12/06/2011 08:20 PM, Daniel Richard G. wrote:
>> I wanted a solution that worked
>> on any POSIX platform -- POSIX 2008 says that
>> $(aaa${bbb}) is just as unspecified as
>> $(aaa$(bbb)) is, and I wanted to play it safe.
>>
> As I see it, the only real way to play it safe here, per POSIX, is to
> forgo the use of nested variables altogether.

Exactly.  Hence the proposal for a configure-time check, which expands
to the extension where the extension was tested to work, and which
expands to an innocuous variant that avoids nested variables where the
test fails.

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

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

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

From: "Daniel Richard G." <skunk <at> iSKUNK.ORG>
To: "Eric Blake" <eblake <at> redhat.com>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>,
	Stefano Lattarini <stefano.lattarini <at> gmail.com>, 10237 <at> debbugs.gnu.org
Subject: Re: bug#10237: AM_SILENT_RULES does not work with NonStop make
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. || skunk <at> iSKUNK.ORG
My ASCII-art .sig got a bad case of Times New Roman.

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

From: Roumen Petrov <bugtrack <at> roumenpetrov.info>
To: 10237 <at> debbugs.gnu.org
Cc: Stefano Lattarini <stefano.lattarini <at> gmail.com>,
	Paul Eggert <eggert <at> cs.ucla.edu>, Eric Blake <eblake <at> redhat.com>,
	"Daniel Richard G." <skunk <at> iSKUNK.ORG>
Subject: Re: bug#10237: AM_SILENT_RULES does not work with NonStop make
Date: Wed, 07 Dec 2011 22:54:12 +0200

Eric Blake wrote:
> On 12/06/2011 08:20 PM, Daniel Richard G. wrote:
>    
>>> I wanted a solution that worked
>>> on any POSIX platform -- POSIX 2008 says that
>>> $(aaa${bbb}) is just as unspecified as
>>> $(aaa$(bbb)) is, and I wanted to play it safe.
>>>
>>>        
>> As I see it, the only real way to play it safe here, per POSIX, is to
>> forgo the use of nested variables altogether.
>>      
> Exactly.  Hence the proposal for a configure-time check, which expands
> to the extension where the extension was tested to work, and which
> expands to an innocuous variant that avoids nested variables where the
> test fails.
>    

I remember one old discussion from automake list that end with following 
solution
lib_LTLIBRARIES = @MODULE@.la
@MODULE <at> _la_SOURCES = module.c
@MODULE <at> _la_LDFLAGS = -module -avoid-version

Following current discussion I think that next will be automake to be 
able to process following Makefile.am

MODULE = @MODULE@
lib_LTLIBRARIES = $(MODULE).la
$(MODULE)_la_SOURCES = module.c
$(MODULE)_la_LDFLAGS = -module -avoid-version

I think that is too early to request such automake functionality .

Roumen

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

From: Eric Blake <eblake <at> redhat.com>
To: Roumen Petrov <bugtrack <at> roumenpetrov.info>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>,
	Stefano Lattarini <stefano.lattarini <at> gmail.com>,
	10237 <at> debbugs.gnu.org, "Daniel Richard G." <skunk <at> iSKUNK.ORG>
Subject: Re: bug#10237: AM_SILENT_RULES does not work with NonStop make
Date: Wed, 07 Dec 2011 14:01:04 -0700

[Message part 1 (text/plain, inline)]

On 12/07/2011 01:54 PM, Roumen Petrov wrote:
>> Exactly.  Hence the proposal for a configure-time check, which expands
>> to the extension where the extension was tested to work, and which
>> expands to an innocuous variant that avoids nested variables where the
>> test fails.
>>    
> 
> I remember one old discussion from automake list that end with following
> solution
> lib_LTLIBRARIES = @MODULE@.la
> @MODULE <at> _la_SOURCES = module.c
> @MODULE <at> _la_LDFLAGS = -module -avoid-version

How is that relavant to this bug?  The whole point of Paul's proposal is
that @AM_V@ and @AM_DEFAULT_VERBOSITY@ are automake internals, and
appear only in Makefile.in, not Makefile.am.

> 
> Following current discussion I think that next will be automake to be
> able to process following Makefile.am
> 
> MODULE = @MODULE@
> lib_LTLIBRARIES = $(MODULE).la
> $(MODULE)_la_SOURCES = module.c
> $(MODULE)_la_LDFLAGS = -module -avoid-version

You're asking for something different, which is a smarter automake that
can handle Makefile.am in such a way that it can see through a
user-provided @MODULE@, even when it is later spelled $(MODULE).  But
that is unrelated to fixing AM_SILENT_RULES to produce POSIX-compliant
makefiles.

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

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

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 9928 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.com>, 10237 <at> debbugs.gnu.org,
	skunk <at> iskunk.org
Subject: Re: bug#10237: AM_SILENT_RULES does not work with NonStop make
Date: Sat, 10 Dec 2011 14:57:49 -0800

[Message part 1 (text/plain, inline)]

On 12/06/11 11:02, Stefano Lattarini wrote:
> If you are interested in accomodating this fringe situation, I will
> then accept a patch on the lines Paul has proposed (with a mandatory
> testcase, otherwise it would be far too easy to regress in such a
> almost-never-excercised corner case).

OK, a proposed patch is below.  It changes the silent-rules test case
to check the new behavior; hope that's what you're asking for.
Comments are welcome.

The patch below is just the human-edited parts.  A full patch
(including the autogenerated parts) is attached, as a compressed file.

automake: port silent-rules option to POSIX make
This fixes two problems reported for Automake (Bug#9928, Bug#10237)
and is in response to a bug report for building coreutils on
HP NonStop OS (Bug#10234).  The basic idea is that instead of
generating Makefile.in lines like "AM_V_CC = $(am__v_CC_$(V))",
we generate "AM_V_CC = $(am__v_CC_ <at> am__V@)".  We then AC_SUBST
$(V) for @am__V@ in the usual case where `make' supports
nested variables, and substitute 1 (or 0) otherwise.
Similarly for usages like $(am__v_CC_$(AM_DEFAULT_VERBOSITY)).
* NEWS: Document this.
* automake.in (define_verbose_var): When defining the variable,
use @am__V@ rather than $(V), and likewise for
@am__DEFAULT_VERBOSITY@ and $(AM_DEFAULT_VERBOSITY).
(handle_options): silent-rules no longer overrides
portability-recursive.
* doc/automake.texi (Invoking Automake): silent-rules no longer
overrides portability-recursive.
(Automake silent-rules Option): Explain new system.
* m4/silent.m4 (AM_SILENT_RULES): Check whether `make' supports
nested variables, and substitute am__V and am__DEFAULT_VERBOSITY
accordingly.
* tests/silent-nowarn.test: Check that silent-rules no longer
overrides portability-recursive.
diff --git a/NEWS b/NEWS
index da9af08..615f420 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,14 @@
+* Changes to automake:
+
+  - The `silent-rules' option now generates working makefiles even for
+    the uncommon `make' implementations that do not support the
+    nested-variables extension to POSIX 2008.  For such `make'
+    implementations, whether a build is silent is determined at
+    configure time, and cannot be overridden at make time with `make
+    V=0' or `make V=1'.  Since the `silent-rules' option no longer
+    requires nested variables, it no longer disables the
+    nested-variables warning.
+
 New in 1.11a:

 * Changes to automake:
diff --git a/automake.in b/automake.in
index 0b6d014..d61af86 100644
--- a/automake.in
+++ b/automake.in
@@ -1141,9 +1141,8 @@ sub define_verbose_var ($$)
     my $silent_var = $pvar . '_0';
     if (option 'silent-rules')
       {
-	# Using `$V' instead of `$(V)' breaks IRIX make.
-	define_variable ($var, '$(' . $pvar . '_$(V))', INTERNAL);
-	define_variable ($pvar . '_', '$(' . $pvar . '_$(AM_DEFAULT_VERBOSITY))', INTERNAL);
+	define_variable ($var, '$(' . $pvar . '_@'.'am__V'.'@)', INTERNAL);
+	define_variable ($pvar . '_', '$(' . $pvar . '_@'.'am__DEFAULT_VERBOSITY'.'@)', INTERNAL);
 	Automake::Variable::define ($silent_var, VAR_AUTOMAKE, '', TRUE, $val,
 				    '', INTERNAL, VAR_ASIS)
 	  if (! vardef ($silent_var, TRUE));
@@ -1236,10 +1235,6 @@ sub handle_options
       return 1 if process_option_list (@options);
     }

-  # Override portability-recursive warning.
-  switch_warning ('no-portability-recursive')
-    if option 'silent-rules';
-
   if ($strictness == GNITS)
     {
       set_option ('readme-alpha', INTERNAL);
diff --git a/doc/automake.texi b/doc/automake.texi
index e937715..8214787 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -2702,8 +2702,6 @@ variables.
 The categories output by default are @samp{syntax} and
 @samp{unsupported}.  Additionally, @samp{gnu} and @samp{portability}
 are enabled in @option{--gnu} and @option{--gnits} strictness.
-On the other hand, the @option{silent-rules} options (@pxref{Options})
-turns off portability warnings about recursive variable expansions.

 @c Checked by extra-portability.test
 Turning off @samp{portability} will also turn off @samp{extra-portability},
@@ -10141,19 +10139,14 @@ Users who prefer to have silent rules enabled by default can edit their
 default to @samp{yes}.  This should still allow disabling silent rules
 at @command{configure} time and at @command{make} time.

-@c FIXME: there's really a need to specify this explicitly?
-For portability to different @command{make} implementations, package authors
-are advised to not set the variable @code{V} inside the @file{Makefile.am}
-file, to allow the user to override the value for subdirectories as well.
-
-The current implementation of this feature relies on a non-POSIX, but in
-practice rather widely supported @file{Makefile} construct of nested
-variable expansion @samp{$(@var{var1}$(V))}.  Do not use the
-@option{silent-rules} option if your package needs to build with
-@command{make} implementations that do not support it.  The
-@option{silent-rules} option turns off warnings about recursive variable
-expansion, which are in turn enabled by @option{-Wportability}
-(@pxref{Invoking Automake}).
+The current implementation of this feature normally uses nested
+variable expansion @samp{$(@var{var1}$(V))}, a @file{Makefile} feature
+that is not required by POSIX 2008 but is widely supported in
+practice.  On the rare @command{make} implementations that do not
+support nested variable expansion, whether rules are silent is always
+determined at configure time, and cannot be overridden at make time.
+Future versions of POSIX are likely to require nested variable
+expansion, so this minor limitation should go away with time.

 @vindex @code{AM_V_GEN}
 @vindex @code{AM_V_at}
diff --git a/m4/silent.m4 b/m4/silent.m4
index 432dd45..2a4446c 100644
--- a/m4/silent.m4
+++ b/m4/silent.m4
@@ -5,7 +5,7 @@
 # gives unlimited permission to copy and/or distribute it,
 # with or without modifications, as long as this notice is preserved.

-# serial 2
+# serial 3

 # AM_SILENT_RULES([DEFAULT])
 # --------------------------
@@ -25,6 +25,34 @@ case $enable_silent_rules in @%:@ (((
    no) AM_DEFAULT_VERBOSITY=1;;
     *) AM_DEFAULT_VERBOSITY=m4_if([$1], [yes], [0], [1]);;
 esac
+am_make=${MAKE-make}
+AC_CACHE_CHECK([whether $am_make supports nested variables],
+   [am_cv_make_nested_variables],
+   [am_makefile='
+TRUE=$(BAR$(V))
+BAR0=false
+BAR1=true
+V=1
+am__doit:
+	@$(TRUE)
+.PHONY: am__doit
+'
+if echo "$am_makefile" | $am_make -s -f - >/dev/null 2>&1; then
+  am_cv_make_nested_variables=yes
+else
+  am_cv_make_nested_variables=no
+fi])
+if test $am_cv_make_nested_variables = yes; then
+  am__V='$(V)'
+  am__DEFAULT_VERBOSITY='$(AM_DEFAULT_VERBOSITY)'
+else
+  am__V=$AM_DEFAULT_VERBOSITY
+  am__DEFAULT_VERBOSITY=$AM_DEFAULT_VERBOSITY
+fi
+AC_SUBST([am__V])dnl
+AM_SUBST_NOTMAKE([am__V])dnl
+AC_SUBST([am__DEFAULT_VERBOSITY])dnl
+AM_SUBST_NOTMAKE([am__DEFAULT_VERBOSITY])dnl
 AC_SUBST([AM_DEFAULT_VERBOSITY])dnl
 AM_BACKSLASH='\'
 AC_SUBST([AM_BACKSLASH])dnl
diff --git a/tests/silent-nowarn.test b/tests/silent-nowarn.test
index f0f5e70..9742bc3 100755
--- a/tests/silent-nowarn.test
+++ b/tests/silent-nowarn.test
@@ -14,7 +14,7 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see <http://www.gnu.org/licenses/>.

-# Check that the 'silent-rules' mode suppresses the warnings for recursive
+# Check that the 'silent-rules' mode does not suppress warnings for recursive
 # make variable expansions.  This should happen regardless of whether and
 # where these warnings are requested.

@@ -39,6 +39,5 @@ END
 touch AUTHORS ChangeLog COPYING INSTALL NEWS README THANKS

 $ACLOCAL
-$AUTOMAKE --gnu -Wall -Wportability-recursive
-
-:
+AUTOMAKE_fails --gnu -Wall -Wportability-recursive
+grep 'recursive variable expansion' stderr

[full-patch.gz (application/x-gzip, attachment)]

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 9928 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.com>, 10237 <at> debbugs.gnu.org,
	skunk <at> iskunk.org
Subject: Re: bug#10237: AM_SILENT_RULES does not work with NonStop make
Date: Sun, 11 Dec 2011 10:42:44 +0100

Hi Paul.

On Saturday 10 December 2011, Paul Eggert wrote:
> On 12/06/11 11:02, Stefano Lattarini wrote:
> > If you are interested in accomodating this fringe situation, I will
> > then accept a patch on the lines Paul has proposed (with a mandatory
> > testcase, otherwise it would be far too easy to regress in such a
> > almost-never-excercised corner case).
> 
> OK, a proposed patch is below.  It changes the silent-rules test case
> to check the new behavior; hope that's what you're asking for.
>
No, I was asking for a test case that simulates the presence of a
make implementation unable to grasp nested variable expansions, that
checks that the new code correctly kicks in such a situation (this
can be done by grepping configure output and generated Makefile),
and that the build process truly works as expected both with
`--enable-silent-rules' and with `--disable-silent-rules' (see test
`silent.test' for inspiration about how to do so).  Otherwise the
new code would remain basically uncovered in our testsuite for the
very fringe and thorny situation we are trying to fix, which IMO is
a big no-no.

> Comments are welcome.
>
See them inlined below.

> The patch below is just the human-edited parts.  A full patch
> (including the autogenerated parts) is attached, as a compressed file.
>

First nit: since this patch is a basically a bugfix (albeit for a very
corner-case bug), I think it should be applied to the maintenance
line of automake.  So, could you please rebase your patch on maint?
Thanks.

> automake: port silent-rules option to POSIX make
>
s/POSIX make/fringe make implementations/, maybe?

> This fixes two problems reported for Automake (Bug#9928, Bug#10237)
> and is in response to a bug report for building coreutils on
> HP NonStop OS (Bug#10234).
>
A brief description of the problem here would be nice.  Would you mind
condensing one from the mailing list discussions?

> The basic idea is that instead of
> generating Makefile.in lines like "AM_V_CC = $(am__v_CC_$(V))",
> we generate "AM_V_CC = $(am__v_CC_ <at> am__V@)".  We then AC_SUBST
> $(V) for @am__V@ in the usual case where `make' supports
> nested variables, and substitute 1 (or 0) otherwise.
>
Here I'd add something like:

  With this change, make implementations that doesn't grasp nested
  variable expansions will still be able to run Makefile generated
  using the `silent-rules' option; of course, they won't allow the
  user to override the make verbosity at runtime through redefintion
  of $(V) (as in "make V=0"); but this is still an improvement over
  not being able to work at all.

> Similarly for usages like $(am__v_CC_$(AM_DEFAULT_VERBOSITY)).
> * NEWS: Document this.
> * automake.in (define_verbose_var): When defining the variable,
> use @am__V@ rather than $(V),

> and likewise for @am__DEFAULT_VERBOSITY@ and $(AM_DEFAULT_VERBOSITY).
>
Maybe substitute this with a simpler "and @am__DEFAULT_VERBOSITY@
rather than $(AM_DEFAULT_VERBOSITY)" ?

> (handle_options): silent-rules no longer overrides
> portability-recursive.
>
Bad idea, unless you also change the documentation in the manual
about how to write custom "silenceable rules":

  You can add your own variables, so strings of your own choice are shown.
  The following snippet shows how you would define your own equivalent of
  AM_V_GEN: 
               pkg_verbose = $(pkg_verbose_$(V))
               pkg_verbose_ = $(pkg_verbose_$(AM_DEFAULT_VERBOSITY))
               pkg_verbose_0 = @echo GEN $@;
               
               foo: foo.in
                       $(pkg_verbose)cp $(srcdir)/foo.in $@

> * doc/automake.texi (Invoking Automake): silent-rules no longer
> overrides portability-recursive.
> (Automake silent-rules Option): Explain new system.
> * m4/silent.m4 (AM_SILENT_RULES): Check whether `make' supports
> nested variables, and substitute am__V and am__DEFAULT_VERBOSITY
> accordingly.
> * tests/silent-nowarn.test: Check that silent-rules no longer
> overrides portability-recursive.
> diff --git a/NEWS b/NEWS
> index da9af08..615f420 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -1,3 +1,14 @@
> +* Changes to automake:
> +
> +  - The `silent-rules' option now generates working makefiles even for
> +    the uncommon `make' implementations that do not support the
> +    nested-variables extension to POSIX 2008.  For such `make'
> +    implementations, whether a build is silent is determined at
> +    configure time, and cannot be overridden at make time with `make
> +    V=0' or `make V=1'.  Since the `silent-rules' option no longer
> +    requires nested variables, it no longer disables the
> +    nested-variables warning.
> +
>
This NEWS entry should go in the "Bugs fixed in 1.11a" section,
"Bugs introduced by 1.11" subsection.

> diff --git a/automake.in b/automake.in
> index 0b6d014..d61af86 100644
> --- a/automake.in
> +++ b/automake.in
> @@ -1141,9 +1141,8 @@ sub define_verbose_var ($$)
>      my $silent_var = $pvar . '_0';
>      if (option 'silent-rules')
>        {
> -	# Using `$V' instead of `$(V)' breaks IRIX make.
>
Here, I'd add a pointer to comments in m4/silent.m4, since this code
has become decidedly non-obvious enough to deserve an examplnation.

> -	define_variable ($var, '$(' . $pvar . '_$(V))', INTERNAL);
> -	define_variable ($pvar . '_', '$(' . $pvar . '_$(AM_DEFAULT_VERBOSITY))', INTERNAL);
> +	define_variable ($var, '$(' . $pvar . '_@'.'am__V'.'@)', INTERNAL);
> +	define_variable ($pvar . '_', '$(' . $pvar . '_@'.'am__DEFAULT_VERBOSITY'.'@)', INTERNAL);
>  	Automake::Variable::define ($silent_var, VAR_AUTOMAKE, '', TRUE, $val,
>  				    '', INTERNAL, VAR_ASIS)
>  	  if (! vardef ($silent_var, TRUE));
> @@ -1236,10 +1235,6 @@ sub handle_options
>        return 1 if process_option_list (@options);
>      }
> 
> -  # Override portability-recursive warning.
> -  switch_warning ('no-portability-recursive')
> -    if option 'silent-rules';
> -
>
Don't do this without also updating the documentation.  Thanks.

>    if ($strictness == GNITS)
>      {
>        set_option ('readme-alpha', INTERNAL);
> diff --git a/doc/automake.texi b/doc/automake.texi
> index e937715..8214787 100644
> --- a/doc/automake.texi
> +++ b/doc/automake.texi
> @@ -2702,8 +2702,6 @@ variables.
>  The categories output by default are @samp{syntax} and
>  @samp{unsupported}.  Additionally, @samp{gnu} and @samp{portability}
>  are enabled in @option{--gnu} and @option{--gnits} strictness.
> -On the other hand, the @option{silent-rules} options (@pxref{Options})
> -turns off portability warnings about recursive variable expansions.
>
>  @c Checked by extra-portability.test
>  Turning off @samp{portability} will also turn off @samp{extra-portability},
> @@ -10141,19 +10139,14 @@ Users who prefer to have silent rules enabled by default can edit their
>  default to @samp{yes}.  This should still allow disabling silent rules
>  at @command{configure} time and at @command{make} time.
> 
> -@c FIXME: there's really a need to specify this explicitly?
> -For portability to different @command{make} implementations, package authors
> -are advised to not set the variable @code{V} inside the @file{Makefile.am}
> -file, to allow the user to override the value for subdirectories as well.
> -
Whay are you removing this advice?

> -The current implementation of this feature relies on a non-POSIX, but in
> -practice rather widely supported @file{Makefile} construct of nested
> -variable expansion @samp{$(@var{var1}$(V))}.  Do not use the
> -@option{silent-rules} option if your package needs to build with
> -@command{make} implementations that do not support it.  The
> -@option{silent-rules} option turns off warnings about recursive variable
> -expansion, which are in turn enabled by @option{-Wportability}
> -(@pxref{Invoking Automake}).
> +The current implementation of this feature normally uses nested
> +variable expansion @samp{$(@var{var1}$(V))}, a @file{Makefile} feature
> +that is not required by POSIX 2008 but is widely supported in
> +practice.  On the rare @command{make} implementations that do not
> +support nested variable expansion, whether rules are silent is always
> +determined at configure time, and cannot be overridden at make time.
>
> +Future versions of POSIX are likely to require nested variable
> +expansion, so this minor limitation should go away with time.
> 
>  @vindex @code{AM_V_GEN}
>  @vindex @code{AM_V_at}
> diff --git a/m4/silent.m4 b/m4/silent.m4
> index 432dd45..2a4446c 100644
> --- a/m4/silent.m4
> +++ b/m4/silent.m4
> @@ -5,7 +5,7 @@
>  # gives unlimited permission to copy and/or distribute it,
>  # with or without modifications, as long as this notice is preserved.
> 
> -# serial 2
> +# serial 3
> 
>  # AM_SILENT_RULES([DEFAULT])
>  # --------------------------
> @@ -25,6 +25,34 @@ case $enable_silent_rules in @%:@ (((
>     no) AM_DEFAULT_VERBOSITY=1;;
>      *) AM_DEFAULT_VERBOSITY=m4_if([$1], [yes], [0], [1]);;
>  esac
> +am_make=${MAKE-make}
> +AC_CACHE_CHECK([whether $am_make supports nested variables],
>
Here, I'd add a short comment for why this is needed, give a
pointer to the bug reports this code is trying to fix.  For
example:

  # Some fringe make implementations (e.g., NonStop make and
  # NextStep make) don't grasp nested variable expansions.
  # See automake bug#10237 and bug#9928.

> +   [am_cv_make_nested_variables],
>
Hmmm... maybe a name like `am_cv_make_support_nested_variables'
would be more appropriate?  Or would it be just longer?

> +   [am_makefile='
> +TRUE=$(BAR$(V))
> +BAR0=false
> +BAR1=true
> +V=1
> +am__doit:
> +	@$(TRUE)
> +.PHONY: am__doit
> +'
> +if echo "$am_makefile" | $am_make -s -f - >/dev/null 2>&1; then
>
`-s' make option shouldn't be needed here; also, I'd use AS_ECHO
instead of bare echo, even if that is probably not required (call
it extra safety, or cargo-cult programmming if you want :-)

> +  am_cv_make_nested_variables=yes
> +else
> +  am_cv_make_nested_variables=no
> +fi])
> +if test $am_cv_make_nested_variables = yes; then
> +  am__V='$(V)'
>
Please re-add here the comment you've removed from automake.in:

   # Using `$V' instead of `$(V)' would break IRIX make.
   am__V='$(V)'

> +  am__DEFAULT_VERBOSITY='$(AM_DEFAULT_VERBOSITY)'
> +else
> +  am__V=$AM_DEFAULT_VERBOSITY
> +  am__DEFAULT_VERBOSITY=$AM_DEFAULT_VERBOSITY
> +fi
> +AC_SUBST([am__V])dnl
> +AM_SUBST_NOTMAKE([am__V])dnl
> +AC_SUBST([am__DEFAULT_VERBOSITY])dnl
> +AM_SUBST_NOTMAKE([am__DEFAULT_VERBOSITY])dnl
>  AC_SUBST([AM_DEFAULT_VERBOSITY])dnl
>  AM_BACKSLASH='\'
>  AC_SUBST([AM_BACKSLASH])dnl

> diff --git a/tests/silent-nowarn.test b/tests/silent-nowarn.test
> index f0f5e70..9742bc3 100755
> --- a/tests/silent-nowarn.test
> +++ b/tests/silent-nowarn.test
> @@ -14,7 +14,7 @@
>  # You should have received a copy of the GNU General Public License
>  # along with this program.  If not, see <http://www.gnu.org/licenses/>.
> 
> -# Check that the 'silent-rules' mode suppresses the warnings for recursive
> +# Check that the 'silent-rules' mode does not suppress warnings for recursive
>  # make variable expansions.  This should happen regardless of whether and
>  # where these warnings are requested.
> 
> @@ -39,6 +39,5 @@ END
>  touch AUTHORS ChangeLog COPYING INSTALL NEWS README THANKS
> 
>  $ACLOCAL
> -$AUTOMAKE --gnu -Wall -Wportability-recursive
> -
> -:
> +AUTOMAKE_fails --gnu -Wall -Wportability-recursive
> +grep 'recursive variable expansion' stderr
> 
Please keep the trailing `:' here:

  AUTOMAKE_fails --gnu -Wall -Wportability-recursive
  grep 'recursive variable expansion' stderr
  
  :

Thanks,
  Stefano
 

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 9928 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.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, 20 Dec 2011 17:30:20 -0800

On 12/11/11 01:42, Stefano Lattarini wrote:

> I was asking for a test case that simulates the presence of a
> make implementation unable to grasp nested variable expansions

Ah, OK, revised patch enclosed below.  This patch should address
your other comments too.  Thanks for the careful review.

From 07edd4aa81af2a8fb982427705a2009c2b7eb0bf Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Tue, 20 Dec 2011 17:29:06 -0800
Subject: [PATCH] automake: silent-rules no longer requires nested vars

This fixes two problems reported for Automake (Bug#9928, Bug#10237)
and is in response to a bug report for building coreutils on HP
NonStop OS (Bug#10234).  The problem is that HP NonStop 'make'
treats a line like "AM_V_CC = $(am__v_CC_$(V))" as one that
expands a macro with the funny name am__v_CC_$(V instead of the
desired name am__v_CC_1 or am__v_CC_0, and since the funny macro
is not defined the line is equivalent to "AM_V_CC = )"; this
inserts a stray ")" when $(AM_V_CC) is used, which eventually
causes 'make' to fail.

The basic idea is that instead of generating Makefile.in lines like
"AM_V_CC = $(am__v_CC_$(V))", we generate
"AM_V_CC = $(am__v_CC_ <at> AM_V@)".  We then AC_SUBST $(V) for @AM_V@
in the usual case where `make' supports nested variables,
and substitute 1 (or 0) otherwise.  Similarly for usages like
$(am__v_CC_$(AM_DEFAULT_VERBOSITY)).

With this change, make implementations that doesn't grasp nested
variable expansions will still be able to run Makefiles generated
using the silent-rules option.  They won't allow the user to
override the make verbosity at runtime through redefinition of
$(V) (as in "make V=0"); but this is still an improvement over not
being able to work at all.

* NEWS: Document this.
* automake.in (define_verbose_var): When defining the variable,
use @AM_V@ rather than $(V), and use
@AM_AM_DEFAULT_VERBOSITY@ rather than $(AM_DEFAULT_VERBOSITY).
* doc/automake.texi (Automake silent-rules Option): Explain new system.
* m4/silent.m4 (AM_SILENT_RULES): Check whether `make' supports
nested variables, and substitute AM_V and AM_AM_DEFAULT_VERBOSITY
accordingly.
* tests/silent-nested-vars.test: New file.
* tests/Makefile.am (TESTS): Add it.
* tests/Makefile.in: Regenerate.
---
 ChangeLog                     |   40 +++++++++++++++
 NEWS                          |    7 +++
 automake.in                   |    9 ++-
 doc/automake.texi             |   22 +++++----
 m4/silent.m4                  |   33 +++++++++++-
 tests/Makefile.am             |    1 +
 tests/Makefile.in             |    1 +
 tests/silent-nested-vars.test |  111 +++++++++++++++++++++++++++++++++++++++++
 8 files changed, 209 insertions(+), 15 deletions(-)
 create mode 100755 tests/silent-nested-vars.test

diff --git a/ChangeLog b/ChangeLog
index 49b6e8b..b2d6e11 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,43 @@
+2011-12-11  Paul Eggert  <eggert <at> cs.ucla.edu>
+
+	automake: silent-rules no longer requires nested vars
+
+	This fixes two problems reported for Automake (Bug#9928, Bug#10237)
+	and is in response to a bug report for building coreutils on HP
+	NonStop OS (Bug#10234).  The problem is that HP NonStop 'make'
+	treats a line like "AM_V_CC = $(am__v_CC_$(V))" as one that
+	expands a macro with the funny name am__v_CC_$(V instead of the
+	desired name am__v_CC_1 or am__v_CC_0, and since the funny macro
+	is not defined the line is equivalent to "AM_V_CC = )"; this
+	inserts a stray ")" when $(AM_V_CC) is used, which eventually
+	causes 'make' to fail.
+
+	The basic idea is that instead of generating Makefile.in lines like
+	"AM_V_CC = $(am__v_CC_$(V))", we generate
+	"AM_V_CC = $(am__v_CC_ <at> AM_V@)".  We then AC_SUBST $(V) for @AM_V@
+	in the usual case where `make' supports nested variables,
+	and substitute 1 (or 0) otherwise.  Similarly for usages like
+	$(am__v_CC_$(AM_DEFAULT_VERBOSITY)).
+
+	With this change, make implementations that doesn't grasp nested
+	variable expansions will still be able to run Makefiles generated
+	using the silent-rules option.  They won't allow the user to
+	override the make verbosity at runtime through redefinition of
+	$(V) (as in "make V=0"); but this is still an improvement over not
+	being able to work at all.
+
+	* NEWS: Document this.
+	* automake.in (define_verbose_var): When defining the variable,
+	use @AM_V@ rather than $(V), and use
+	@AM_AM_DEFAULT_VERBOSITY@ rather than $(AM_DEFAULT_VERBOSITY).
+	* doc/automake.texi (Automake silent-rules Option): Explain new system.
+	* m4/silent.m4 (AM_SILENT_RULES): Check whether `make' supports
+	nested variables, and substitute AM_V and AM_AM_DEFAULT_VERBOSITY
+	accordingly.
+	* tests/silent-nested-vars.test: New file.
+	* tests/Makefile.am (TESTS): Add it.
+	* tests/Makefile.in: Regenerate.
+
 2011-12-20  Peter Rosin  <peda <at> lysator.liu.se>
 
 	tests: fix spurious failure on systems lacking unistd.h
diff --git a/NEWS b/NEWS
index 46803a7..58c90c9 100644
--- a/NEWS
+++ b/NEWS
@@ -74,6 +74,13 @@ Bugs fixed in 1.11.0a:
     not used, `make' output no longer contains spurious backslash-only
     lines, thus once again matching what Automake did before 1.11.
 
+  - The `silent-rules' option now generates working makefiles even for
+    the uncommon `make' implementations that do not support the
+    nested-variables extension to POSIX 2008.  For such `make'
+    implementations, whether a build is silent is determined at
+    configure time, and cannot be overridden at make time with `make
+    V=0' or `make V=1'.
+
   - The AM_COND_IF macro also works if the shell expression for the conditional
     is no longer valid for the condition.
 
diff --git a/automake.in b/automake.in
index db7f3c6..ae2011c 100755
--- a/automake.in
+++ b/automake.in
@@ -1161,9 +1161,12 @@ sub define_verbose_var ($$)
     my $silent_var = $pvar . '_0';
     if (option 'silent-rules')
       {
-	# Using `$V' instead of `$(V)' breaks IRIX make.
-	define_variable ($var, '$(' . $pvar . '_$(V))', INTERNAL);
-	define_variable ($pvar . '_', '$(' . $pvar . '_$(AM_DEFAULT_VERBOSITY))', INTERNAL);
+	# For typical `make's, `configure' replaces AM_V (inside @@) with $(V)
+	# and AM_AM_DEFAULT_VERBOSITY (inside @@) with $(AM_DEFAULT_VERBOSITY).
+	# For strict POSIX 2008 `make's, it replaces them with 0 or 1 instead.
+	# See AM_SILENT_RULES in m4/silent.m4.
+	define_variable ($var, '$(' . $pvar . '_@'.'AM_V'.'@)', INTERNAL);
+	define_variable ($pvar . '_', '$(' . $pvar . '_@'.'AM_AM_DEFAULT_VERBOSITY'.'@)', INTERNAL);
 	Automake::Variable::define ($silent_var, VAR_AUTOMAKE, '', TRUE, $val,
 				    '', INTERNAL, VAR_ASIS)
 	  if (! vardef ($silent_var, TRUE));
diff --git a/doc/automake.texi b/doc/automake.texi
index a5f857d..1a689b6 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -10130,18 +10130,20 @@ For portability to different @command{make} implementations, package authors
 are advised to not set the variable @code{V} inside the @file{Makefile.am}
 file, to allow the user to override the value for subdirectories as well.
 
-The current implementation of this feature relies on a non-POSIX, but in
-practice rather widely supported @file{Makefile} construct of nested
-variable expansion @samp{$(@var{var1}$(V))}.  Do not use the
-@option{silent-rules} option if your package needs to build with
-@command{make} implementations that do not support it.  The
-@option{silent-rules} option turns off warnings about recursive variable
-expansion, which are in turn enabled by @option{-Wportability}
-(@pxref{Invoking Automake}).
+The current implementation of this feature normally uses nested
+variable expansion @samp{$(@var{var1}$(V))}, a @file{Makefile} feature
+that is not required by POSIX 2008 but is widely supported in
+practice.  On the rare @command{make} implementations that do not
+support nested variable expansion, whether rules are silent is always
+determined at configure time, and cannot be overridden at make time.
+Future versions of POSIX are likely to require nested variable
+expansion, so this minor limitation should go away with time.
 
 @vindex @code{AM_V_GEN}
 @vindex @code{AM_V_at}
 @vindex @code{AM_DEFAULT_VERBOSITY}
+@vindex @code{AM_V}
+@vindex @code{AM_AM_DEFAULT_VERBOSITY}
 To extend the silent mode to your own rules, you have two choices:
 
 @itemize @bullet
@@ -10157,8 +10159,8 @@ The following snippet shows how you would define your own equivalent of
 @code{AM_V_GEN}:
 
 @example
-pkg_verbose = $(pkg_verbose_$(V))
-pkg_verbose_ = $(pkg_verbose_$(AM_DEFAULT_VERBOSITY))
+pkg_verbose = $(pkg_verbose_@@AM_V@@)
+pkg_verbose_ = $(pkg_verbose_@@AM_AM_DEFAULT_VERBOSITY@@)
 pkg_verbose_0 = @@echo PKG-GEN $@@;
 
 foo: foo.in
diff --git a/m4/silent.m4 b/m4/silent.m4
index 6d2a1a2..1928feb 100644
--- a/m4/silent.m4
+++ b/m4/silent.m4
@@ -1,11 +1,11 @@
 ##                                                          -*- Autoconf -*-
-# Copyright (C) 2009  Free Software Foundation, Inc.
+# Copyright (C) 2009, 2011  Free Software Foundation, Inc.
 #
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
 # with or without modifications, as long as this notice is preserved.
 
-# serial 1
+# serial 2
 
 # AM_SILENT_RULES([DEFAULT])
 # --------------------------
@@ -20,6 +20,35 @@ yes) AM_DEFAULT_VERBOSITY=0;;
 no)  AM_DEFAULT_VERBOSITY=1;;
 *)   AM_DEFAULT_VERBOSITY=m4_if([$1], [yes], [0], [1]);;
 esac
+dnl
+dnl A few `make' implementations (e.g., NonStop OS and NextStep)
+dnl do not support nested variable expansions.
+dnl See automake bug#9928 and bug#10237.
+am_make=${MAKE-make}
+AC_CACHE_CHECK([whether $am_make supports nested variables],
+   [am_cv_make_support_nested_variables],
+   [if AS_ECHO([['TRUE=$(BAR$(V))
+BAR0=false
+BAR1=true
+V=1
+am__doit:
+	@$(TRUE)
+.PHONY: am__doit']]) | $am_make -f - >/dev/null 2>&1; then
+  am_cv_make_support_nested_variables=yes
+else
+  am_cv_make_support_nested_variables=no
+fi])
+if test $am_cv_make_support_nested_variables = yes; then
+  AM_V='$(V)'dnl Using `$V' instead of `$(V)' breaks IRIX make.
+  AM_AM_DEFAULT_VERBOSITY='$(AM_DEFAULT_VERBOSITY)'
+else
+  AM_V=$AM_DEFAULT_VERBOSITY
+  AM_AM_DEFAULT_VERBOSITY=$AM_DEFAULT_VERBOSITY
+fi
+AC_SUBST([AM_V])dnl
+AM_SUBST_NOTMAKE([AM_V])dnl
+AC_SUBST([AM_AM_DEFAULT_VERBOSITY])dnl
+AM_SUBST_NOTMAKE([AM_AM_DEFAULT_VERBOSITY])dnl
 AC_SUBST([AM_DEFAULT_VERBOSITY])dnl
 AM_BACKSLASH='\'
 AC_SUBST([AM_BACKSLASH])dnl
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 831906b..920d994 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -751,6 +751,7 @@ silent-many-gcc.test \
 silent-many-generic.test \
 silent-lex-gcc.test \
 silent-lex-generic.test \
+silent-nested-vars.test \
 silent-yacc-gcc.test \
 silent-yacc-generic.test \
 silent-configsite.test \
diff --git a/tests/Makefile.in b/tests/Makefile.in
index 3ad0146..470ed6c 100644
--- a/tests/Makefile.in
+++ b/tests/Makefile.in
@@ -1035,6 +1035,7 @@ silent-many-gcc.test \
 silent-many-generic.test \
 silent-lex-gcc.test \
 silent-lex-generic.test \
+silent-nested-vars.test \
 silent-yacc-gcc.test \
 silent-yacc-generic.test \
 silent-configsite.test \
diff --git a/tests/silent-nested-vars.test b/tests/silent-nested-vars.test
new file mode 100755
index 0000000..6716930
--- /dev/null
+++ b/tests/silent-nested-vars.test
@@ -0,0 +1,111 @@
+#!/bin/sh
+# Copyright (C) 2011 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# Check silent-rules mode, on 'make' implementations that do not
+# support nested variables.
+
+. ./defs || Exit 1
+
+set -e
+
+mkdir sub
+
+cat >>configure.in <<'EOF'
+AM_SILENT_RULES
+AC_CONFIG_FILES([sub/Makefile])
+AC_PROG_CC
+AM_PROG_CC_C_O
+AC_OUTPUT
+EOF
+
+cat > Makefile.am <<'EOF'
+# Need generic and non-generic rules.
+bin_PROGRAMS = foo bar
+bar_CFLAGS = $(AM_CFLAGS)
+SUBDIRS = sub
+EOF
+
+cat > sub/Makefile.am <<'EOF'
+AUTOMAKE_OPTIONS = subdir-objects
+# Need generic and non-generic rules.
+bin_PROGRAMS = baz bla
+bla_CFLAGS = $(AM_CFLAGS)
+EOF
+
+cat > foo.c <<'EOF'
+int main ()
+{
+  return 0;
+}
+EOF
+cp foo.c bar.c
+cp foo.c sub/baz.c
+cp foo.c sub/bla.c
+
+cat >mymake <<'EOF'
+#! /bin/sh
+makerules=
+
+case $1 in
+  -f)
+    makefile=$2
+    case $2 in
+      -) makerules=`cat` || exit ;;
+    esac ;;
+  *)
+    for makefile in makefile Makefile; do
+      test -f $makefile && break
+    done ;;
+esac
+
+if printf '%s\n' "$makerules" | LC_ALL=C grep '\$([a-zA-Z0-9_]*\$' $makefile
+then
+  echo >&2 "mymake: $makefile contains nested variables"
+  exit 1
+fi
+exec $mymake_MAKE "$@"
+EOF
+chmod a+x mymake
+mymake_MAKE=${MAKE-make}
+export mymake_MAKE
+
+$ACLOCAL
+$AUTOMAKE --add-missing
+$AUTOCONF
+
+./configure --enable-silent-rules MAKE=./mymake
+./mymake >stdout || { cat stdout; Exit 1; }
+cat stdout
+$EGREP ' (-c|-o)' stdout && Exit 1
+grep 'mv ' stdout && Exit 1
+grep 'CC    .*foo\.' stdout
+grep 'CC .*bar\.' stdout
+grep 'CC .*baz\.' stdout
+grep 'CC .*bla\.' stdout
+grep 'CCLD .*foo' stdout
+grep 'CCLD .*bar' stdout
+grep 'CCLD .*baz' stdout
+grep 'CCLD .*bla' stdout
+
+./mymake clean
+./configure --disable-silent-rules MAKE=./mymake
+./mymake >stdout || { cat stdout; Exit 1; }
+cat stdout
+grep ' -c' stdout
+grep ' -o foo' stdout
+$EGREP '(CC|LD) ' stdout && Exit 1
+
+:
-- 
1.7.6.4

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 9928 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.com>, 10237 <at> debbugs.gnu.org,
	skunk <at> iskunk.org
Subject: Re: bug#9928: bug#10237: AM_SILENT_RULES does not work with NonStop
	make
Date: Wed, 21 Dec 2011 13:21:26 +0100

Hi Paul, thanks for the respin.  My comments and objections are inlined.

On 12/21/2011 02:30 AM, Paul Eggert wrote:
> On 12/11/11 01:42, Stefano Lattarini wrote:
> 
>> I was asking for a test case that simulates the presence of a
>> make implementation unable to grasp nested variable expansions
> 
> Ah, OK, revised patch enclosed below.  This patch should address
> your other comments too.  Thanks for the careful review.
> 
> From 07edd4aa81af2a8fb982427705a2009c2b7eb0bf Mon Sep 17 00:00:00 2001
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Tue, 20 Dec 2011 17:29:06 -0800
> Subject: [PATCH] automake: silent-rules no longer requires nested vars
>
This sounds a little misleading to me; i.e., it sounds like we have
reimplemented the silent-rules feature to work completely and at its
best even with make implementations not supporting nested variables,
which is not true.  What about this instead?

  silent-rules: provide fallback for makes without nested variables support

> This fixes two problems reported for Automake (Bug#9928, Bug#10237)
> and is in response to a bug report for building coreutils on HP
> NonStop OS (Bug#10234).  The problem is that HP NonStop 'make'
> treats a line like "AM_V_CC = $(am__v_CC_$(V))" as one that
> expands a macro with the funny name am__v_CC_$(V instead of the
> desired name am__v_CC_1 or am__v_CC_0, and since the funny macro
> is not defined the line is equivalent to "AM_V_CC = )"; this
> inserts a stray ")" when $(AM_V_CC) is used, which eventually
> causes 'make' to fail.
>
Very good explanation.

> The basic idea is that instead of generating Makefile.in lines like
> "AM_V_CC = $(am__v_CC_$(V))", we generate
> "AM_V_CC = $(am__v_CC_ <at> AM_V@)".  We then AC_SUBST $(V) for @AM_V@
> in the usual case where `make' supports nested variables,
> and substitute 1 (or 0) otherwise.  Similarly for usages like
> $(am__v_CC_$(AM_DEFAULT_VERBOSITY)).
> 
> With this change, make implementations that doesn't grasp nested
> variable expansions will still be able to run Makefiles generated
> using the silent-rules option.  They won't allow the user to
> override the make verbosity at runtime through redefinition of
> $(V) (as in "make V=0"); but this is still an improvement over not
> being able to work at all.
>
And all this is good too.  Thanks.

> * NEWS: Document this.
> * automake.in (define_verbose_var): When defining the variable,
> use @AM_V@ rather than $(V), and use
> @AM_AM_DEFAULT_VERBOSITY@ rather than $(AM_DEFAULT_VERBOSITY).
> * doc/automake.texi (Automake silent-rules Option): Explain new system.
> * m4/silent.m4 (AM_SILENT_RULES): Check whether `make' supports
> nested variables, and substitute AM_V and AM_AM_DEFAULT_VERBOSITY
>
s/AM_AM_DEFAULT_VERBOSITY/AM_V_DEFAULT_VERBOSITY/ ?

> accordingly.
> * tests/silent-nested-vars.test: New file.
>
Micro-nit: I'd prefer s/file/test/ here (but this is not a requirement
for an ACK!).

> * tests/Makefile.am (TESTS): Add it.
> * tests/Makefile.in: Regenerate.
>
Small nit: we don't mention changes to autogenerated-but-committed files
in our ChangeLog entries and commit messages.

> ---
>  ChangeLog                     |   40 +++++++++++++++
>  NEWS                          |    7 +++
>  automake.in                   |    9 ++-
>  doc/automake.texi             |   22 +++++----
>  m4/silent.m4                  |   33 +++++++++++-
>  tests/Makefile.am             |    1 +
>  tests/Makefile.in             |    1 +
>  tests/silent-nested-vars.test |  111 +++++++++++++++++++++++++++++++++++++++++
>  8 files changed, 209 insertions(+), 15 deletions(-)
>  create mode 100755 tests/silent-nested-vars.test
> 
> diff --git a/ChangeLog b/ChangeLog
> index 49b6e8b..b2d6e11 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,43 @@
> +2011-12-11  Paul Eggert  <eggert <at> cs.ucla.edu>
> +
>
[SNIP ChangeLog entry]

[The same comments given above for the git commit message  applies, obviously].

> diff --git a/NEWS b/NEWS
> index 46803a7..58c90c9 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -74,6 +74,13 @@ Bugs fixed in 1.11.0a:
>      not used, `make' output no longer contains spurious backslash-only
>      lines, thus once again matching what Automake did before 1.11.
>  
> +  - The `silent-rules' option now generates working makefiles even for
> +    the uncommon `make' implementations that do not support the
> +    nested-variables extension to POSIX 2008.  For such `make'
> +    implementations, whether a build is silent is determined at
> +    configure time, and cannot be overridden at make time with `make
> +    V=0' or `make V=1'.
> +
Very clear, thanks.

>    - The AM_COND_IF macro also works if the shell expression for the conditional
>      is no longer valid for the condition.
>  
> diff --git a/automake.in b/automake.in
> index db7f3c6..ae2011c 100755
> --- a/automake.in
> +++ b/automake.in
> @@ -1161,9 +1161,12 @@ sub define_verbose_var ($$)
>      my $silent_var = $pvar . '_0';
>      if (option 'silent-rules')
>        {
> -	# Using `$V' instead of `$(V)' breaks IRIX make.
> -	define_variable ($var, '$(' . $pvar . '_$(V))', INTERNAL);
> -	define_variable ($pvar . '_', '$(' . $pvar . '_$(AM_DEFAULT_VERBOSITY))', INTERNAL);
> +	# For typical `make's, `configure' replaces AM_V (inside @@) with $(V)
> +	# and AM_AM_DEFAULT_VERBOSITY (inside @@) with $(AM_DEFAULT_VERBOSITY).
>
AM_AM_DEFAULT_VERBOSITY ?  More instances below, in this and other files.

> +	# For strict POSIX 2008 `make's, it replaces them with 0 or 1 instead.
> +	# See AM_SILENT_RULES in m4/silent.m4.
> +	define_variable ($var, '$(' . $pvar . '_@'.'AM_V'.'@)', INTERNAL);
> +	define_variable ($pvar . '_', '$(' . $pvar . '_@'.'AM_AM_DEFAULT_VERBOSITY'.'@)', INTERNAL);
>  	Automake::Variable::define ($silent_var, VAR_AUTOMAKE, '', TRUE, $val,
>  				    '', INTERNAL, VAR_ASIS)
>  	  if (! vardef ($silent_var, TRUE));
> diff --git a/doc/automake.texi b/doc/automake.texi
> index a5f857d..1a689b6 100644
> --- a/doc/automake.texi
> +++ b/doc/automake.texi
> @@ -10130,18 +10130,20 @@ For portability to different @command{make} implementations, package authors
>  are advised to not set the variable @code{V} inside the @file{Makefile.am}
>  file, to allow the user to override the value for subdirectories as well.
>  A
> -The current implementation of this feature relies on a non-POSIX, but in
> -practice rather widely supported @file{Makefile} construct of nested
> -variable expansion @samp{$(@var{var1}$(V))}.  Do not use the
> -@option{silent-rules} option if your package needs to build with
> -@command{make} implementations that do not support it.  The
> -@option{silent-rules} option turns off warnings about recursive variable
> -expansion, which are in turn enabled by @option{-Wportability}
> -(@pxref{Invoking Automake}).
> +The current implementation of this feature normally uses nested
> +variable expansion @samp{$(@var{var1}$(V))}, a @file{Makefile} feature
> +that is not required by POSIX 2008 but is widely supported in
> +practice.  On the rare @command{make} implementations that do not
> +support nested variable expansion, whether rules are silent is always
> +determined at configure time, and cannot be overridden at make time.
> +Future versions of POSIX are likely to require nested variable
> +expansion, so this minor limitation should go away with time.
> 
Good and clear explanation.

>  @vindex @code{AM_V_GEN}
>  @vindex @code{AM_V_at}
>  @vindex @code{AM_DEFAULT_VERBOSITY}
> +@vindex @code{AM_V}
> +@vindex @code{AM_AM_DEFAULT_VERBOSITY}
>
>  To extend the silent mode to your own rules, you have two choices:
>  
>  @itemize @bullet
> @@ -10157,8 +10159,8 @@ The following snippet shows how you would define your own equivalent of
>  @code{AM_V_GEN}:
>  
>  @example
> -pkg_verbose = $(pkg_verbose_$(V))
> -pkg_verbose_ = $(pkg_verbose_$(AM_DEFAULT_VERBOSITY))
> +pkg_verbose = $(pkg_verbose_@@AM_V@@)
> +pkg_verbose_ = $(pkg_verbose_@@AM_AM_DEFAULT_VERBOSITY@@)
>
Do we have a test verifying that the previously documented usage:

  pkg_verbose = $(pkg_verbose_$(V))
  pkg_verbose_ = $(pkg_verbose_$(AM_DEFAULT_VERBOSITY))

still works with make implementations that support nested variable expansion,
as it did before this change?  More importantly, do we have a test verifying
that the new documented usage:

  pkg_verbose = $(pkg_verbose_ <at> AM_V@)
  pkg_verbose_ = $(pkg_verbose_ <at> AM_AM_DEFAULT_VERBOSITY@)

actually works as advised?

>  pkg_verbose_0 = @@echo PKG-GEN $@@;
>  
>  foo: foo.in
> diff --git a/m4/silent.m4 b/m4/silent.m4
> index 6d2a1a2..1928feb 100644
> --- a/m4/silent.m4
> +++ b/m4/silent.m4
> @@ -1,11 +1,11 @@
>  ##                                                          -*- Autoconf -*-
> -# Copyright (C) 2009  Free Software Foundation, Inc.
> +# Copyright (C) 2009, 2011  Free Software Foundation, Inc.
>  #
>  # This file is free software; the Free Software Foundation
>  # gives unlimited permission to copy and/or distribute it,
>  # with or without modifications, as long as this notice is preserved.
>  
> -# serial 1
> +# serial 2
>  
>  # AM_SILENT_RULES([DEFAULT])
>  # --------------------------
> @@ -20,6 +20,35 @@ yes) AM_DEFAULT_VERBOSITY=0;;
>  no)  AM_DEFAULT_VERBOSITY=1;;
>  *)   AM_DEFAULT_VERBOSITY=m4_if([$1], [yes], [0], [1]);;
>  esac
> +dnl
> +dnl A few `make' implementations (e.g., NonStop OS and NextStep)
> +dnl do not support nested variable expansions.
> +dnl See automake bug#9928 and bug#10237.
> +am_make=${MAKE-make}
> +AC_CACHE_CHECK([whether $am_make supports nested variables],
> +   [am_cv_make_support_nested_variables],
> +   [if AS_ECHO([['TRUE=$(BAR$(V))
> +BAR0=false
> +BAR1=true
> +V=1
> +am__doit:
> +	@$(TRUE)
> +.PHONY: am__doit']]) | $am_make -f - >/dev/null 2>&1; then
> +  am_cv_make_support_nested_variables=yes
> +else
> +  am_cv_make_support_nested_variables=no
> +fi])
> +if test $am_cv_make_support_nested_variables = yes; then
> +  AM_V='$(V)'dnl Using `$V' instead of `$(V)' breaks IRIX make.
>
Keep this comment on a separate line maybe?  That would seem clearer to me:

  # Using `$V' instead of `$(V)' breaks IRIX make.
  AM_V='$(V)'

> +  AM_AM_DEFAULT_VERBOSITY='$(AM_DEFAULT_VERBOSITY)'
> +else
> +  AM_V=$AM_DEFAULT_VERBOSITY
> +  AM_AM_DEFAULT_VERBOSITY=$AM_DEFAULT_VERBOSITY
> +fi
> +AC_SUBST([AM_V])dnl
> +AM_SUBST_NOTMAKE([AM_V])dnl
> +AC_SUBST([AM_AM_DEFAULT_VERBOSITY])dnl
> +AM_SUBST_NOTMAKE([AM_AM_DEFAULT_VERBOSITY])dnl
>  AC_SUBST([AM_DEFAULT_VERBOSITY])dnl
>  AM_BACKSLASH='\'
>  AC_SUBST([AM_BACKSLASH])dnl

> diff --git a/tests/Makefile.am b/tests/Makefile.am
> index 831906b..920d994 100644
> --- a/tests/Makefile.am
> +++ b/tests/Makefile.am
> @@ -751,6 +751,7 @@ silent-many-gcc.test \
>  silent-many-generic.test \
>  silent-lex-gcc.test \
>  silent-lex-generic.test \
> +silent-nested-vars.test \
>  silent-yacc-gcc.test \
>  silent-yacc-generic.test \
>  silent-configsite.test \
> diff --git a/tests/Makefile.in b/tests/Makefile.in
> index 3ad0146..470ed6c 100644
> --- a/tests/Makefile.in
> +++ b/tests/Makefile.in
> @@ -1035,6 +1035,7 @@ silent-many-gcc.test \
>  silent-many-generic.test \
>  silent-lex-gcc.test \
>  silent-lex-generic.test \
> +silent-nested-vars.test \
>  silent-yacc-gcc.test \
>  silent-yacc-generic.test \
>  silent-configsite.test \
> diff --git a/tests/silent-nested-vars.test b/tests/silent-nested-vars.test
> new file mode 100755
> index 0000000..6716930
> --- /dev/null
> +++ b/tests/silent-nested-vars.test
> @@ -0,0 +1,111 @@
> +#!/bin/sh
> +# Copyright (C) 2011 Free Software Foundation, Inc.
> +#
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 2, or (at your option)
> +# any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program.  If not, see <http://www.gnu.org/licenses/>.
> +
> +# Check silent-rules mode, on 'make' implementations that do not
> +# support nested variables.
>
Could you please add a reference to the relevant bug numbers here as well?
Thanks.

> +
> +. ./defs || Exit 1
> +
> +set -e
> +
> +mkdir sub
> +
> +cat >>configure.in <<'EOF'
> +AM_SILENT_RULES
> +AC_CONFIG_FILES([sub/Makefile])
> +AC_PROG_CC
> +AM_PROG_CC_C_O
> +AC_OUTPUT
> +EOF
> +
> +cat > Makefile.am <<'EOF'
> +# Need generic and non-generic rules.
> +bin_PROGRAMS = foo bar
> +bar_CFLAGS = $(AM_CFLAGS)
> +SUBDIRS = sub
> +EOF
> +
> +cat > sub/Makefile.am <<'EOF'
> +AUTOMAKE_OPTIONS = subdir-objects
> +# Need generic and non-generic rules.
> +bin_PROGRAMS = baz bla
> +bla_CFLAGS = $(AM_CFLAGS)
> +EOF
> +
Maybe trying out also subdir-objects is an overkill in the context of this
patch ...  Oh well, than can be fixed by a later patch if the need arise,
so let's not worry about it now.

> +cat > foo.c <<'EOF'
> +int main ()
> +{
> +  return 0;
> +}
> +EOF
> +cp foo.c bar.c
> +cp foo.c sub/baz.c
> +cp foo.c sub/bla.c
> +
> +cat >mymake <<'EOF'
> +#! /bin/sh
> +makerules=
> +
> +case $1 in
> +  -f)
> +    makefile=$2
> +    case $2 in
> +      -) makerules=`cat` || exit ;;
> +    esac ;;
> +  *)
> +    for makefile in makefile Makefile; do
> +      test -f $makefile && break
> +    done ;;
> +esac
> +
> +if printf '%s\n' "$makerules" | LC_ALL=C grep '\$([a-zA-Z0-9_]*\$' $makefile
>
This seems wrong, as grep will not consider its standard input when given a
non-empty argument.  Or am I missing something?

> +then
> +  echo >&2 "mymake: $makefile contains nested variables"
> +  exit 1
> +fi
> +exec $mymake_MAKE "$@"
>
What if we had "-f -" among the arguments?  The stdin meant for make will result
to be already consumed by the previous `cat`...

> +EOF
> +chmod a+x mymake
> +mymake_MAKE=${MAKE-make}
> +export mymake_MAKE
> +
I'd add a sanity check here to verify that the `mymake' script really
rejects Makefiles using nested variables:

  cat > Makefile <<'END'
  a = $(b$(c))
  all:
	touch bar
  END
  ./mymake && Exit 99
  mv -f Makefile foo.mk
  ./mymake -f foo.mkr && Exit 99
  cat foo.mk | ./mymake -f - && Exit 99
  test -f bar && Exit 99
  sed '/a =/d' foo.mk > Makefile
  ./mymake && test -f bar || Exit 99
  rm -f foo.mk bar Makefile

Ugly, I know, but similar internal checks have saved me from testsuite bugs and
false negatives a few times already.

> +$ACLOCAL
> +$AUTOMAKE --add-missing
> +$AUTOCONF
> +
> +./configure --enable-silent-rules MAKE=./mymake
>
You should also grep configure output for:

  checking whether ./mymake supports nested variables... no

and maybe the generated Makefile for the definition:

  AM_V = 1

> +./mymake >stdout || { cat stdout; Exit 1; }
> +cat stdout
> +$EGREP ' (-c|-o)' stdout && Exit 1
> +grep 'mv ' stdout && Exit 1
> +grep 'CC    .*foo\.' stdout
> +grep 'CC .*bar\.' stdout
> +grep 'CC .*baz\.' stdout
> +grep 'CC .*bla\.' stdout
> +grep 'CCLD .*foo' stdout
> +grep 'CCLD .*bar' stdout
> +grep 'CCLD .*baz' stdout
> +grep 'CCLD .*bla' stdout
> +
> +./mymake clean

> +./configure --disable-silent-rules MAKE=./mymake
>
You should also grep configure output for:

  checking whether ./mymake supports nested variables... no

and maybe the generated Makefile for the definition:

  AM_V = 0

> +./mymake >stdout || { cat stdout; Exit 1; }
> +cat stdout
> +grep ' -c' stdout
> +grep ' -o foo' stdout
> +$EGREP '(CC|LD) ' stdout && Exit 1
> +
> +:

Thanks,
  Stefano

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 9928 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.com>, 10237 <at> debbugs.gnu.org,
	skunk <at> iskunk.org
Subject: Re: bug#9928: bug#10237: AM_SILENT_RULES does not work with NonStop
	make
Date: Thu, 22 Dec 2011 13:56:22 -0800

On 12/21/11 04:21, Stefano Lattarini wrote:
> Hi Paul, thanks for the respin.  My comments and objections are inlined.

Thanks, I have a patch updated with all those comments in mind.
One followup:

> AM_AM_DEFAULT_VERBOSITY ?

I changed that to AM_DEFAULT_V, as that seems to fit into the naming
convention better.

From 939ba315f5e3e5caea0513af20724c35ead86956 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Thu, 22 Dec 2011 13:48:54 -0800
Subject: [PATCH] silent-rules: fallback for makes without nested vars

This fixes two problems reported for Automake (Bug#9928, Bug#10237)
and is in response to a bug report for building coreutils on HP
NonStop OS (Bug#10234).  The problem is that HP NonStop 'make'
treats a line like "AM_V_CC = $(am__v_CC_$(V))" as one that
expands a macro with the funny name am__v_CC_$(V instead of the
desired name am__v_CC_1 or am__v_CC_0, and since the funny macro
is not defined the line is equivalent to "AM_V_CC = )"; this
inserts a stray ")" when $(AM_V_CC) is used, which eventually
causes 'make' to fail.

The basic idea is that instead of generating Makefile.in lines like
"AM_V_CC = $(am__v_CC_$(V))", we generate
"AM_V_CC = $(am__v_CC_ <at> AM_V@)".  We then AC_SUBST $(V) for @AM_V@
in the usual case where `make' supports nested variables,
and substitute 1 (or 0) otherwise.  Similarly for usages like
$(am__v_CC_$(AM_DEFAULT_VERBOSITY)).

With this change, make implementations that doesn't grasp nested
variable expansions will still be able to run Makefiles generated
using the silent-rules option.  They won't allow the user to
override the make verbosity at runtime through redefinition of
$(V) (as in "make V=0"); but this is still an improvement over not
being able to work at all.

* NEWS: Document this.
* automake.in (define_verbose_var): When defining the variable,
use @AM_V@ rather than $(V), and use @AM_DEFAULT_V@ rather than
$(AM_DEFAULT_VERBOSITY).
* doc/automake.texi (Automake silent-rules Option): Explain new system.
* m4/silent.m4 (AM_SILENT_RULES): Check whether `make' supports
nested variables, and substitute AM_V and AM_DEFAULT_V accordingly.
* tests/silent-nested-vars.test: New test.
* tests/Makefile.am (TESTS): Add it.
---
 ChangeLog                     |   39 ++++++++
 NEWS                          |    7 ++
 automake.in                   |    9 ++-
 doc/automake.texi             |   22 +++--
 m4/silent.m4                  |   34 +++++++-
 tests/Makefile.am             |    1 +
 tests/silent-nested-vars.test |  193 +++++++++++++++++++++++++++++++++++++++++
 7 files changed, 290 insertions(+), 15 deletions(-)
 create mode 100755 tests/silent-nested-vars.test

diff --git a/ChangeLog b/ChangeLog
index 26e4a2d..461dfac 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,42 @@
+2011-12-22  Paul Eggert  <eggert <at> cs.ucla.edu>
+
+	silent-rules: fallback for makes without nested vars
+
+	This fixes two problems reported for Automake (Bug#9928, Bug#10237)
+	and is in response to a bug report for building coreutils on HP
+	NonStop OS (Bug#10234).  The problem is that HP NonStop 'make'
+	treats a line like "AM_V_CC = $(am__v_CC_$(V))" as one that
+	expands a macro with the funny name am__v_CC_$(V instead of the
+	desired name am__v_CC_1 or am__v_CC_0, and since the funny macro
+	is not defined the line is equivalent to "AM_V_CC = )"; this
+	inserts a stray ")" when $(AM_V_CC) is used, which eventually
+	causes 'make' to fail.
+
+	The basic idea is that instead of generating Makefile.in lines like
+	"AM_V_CC = $(am__v_CC_$(V))", we generate
+	"AM_V_CC = $(am__v_CC_ <at> AM_V@)".  We then AC_SUBST $(V) for @AM_V@
+	in the usual case where `make' supports nested variables,
+	and substitute 1 (or 0) otherwise.  Similarly for usages like
+	$(am__v_CC_$(AM_DEFAULT_VERBOSITY)).
+
+	With this change, make implementations that doesn't grasp nested
+	variable expansions will still be able to run Makefiles generated
+	using the silent-rules option.  They won't allow the user to
+	override the make verbosity at runtime through redefinition of
+	$(V) (as in "make V=0"); but this is still an improvement over not
+	being able to work at all.
+
+	* NEWS: Document this.
+	* automake.in (define_verbose_var): When defining the variable,
+	use @AM_V@ rather than $(V), and use @AM_DEFAULT_V@ rather than
+	$(AM_DEFAULT_VERBOSITY).
+	* doc/automake.texi (Automake silent-rules Option): Explain new system.
+	* m4/silent.m4 (AM_SILENT_RULES): Check whether `make' supports
+	nested variables, and substitute AM_V and AM_DEFAULT_V accordingly.
+	* tests/silent-nested-vars.test: New test.
+	* tests/Makefile.am (TESTS): Add it.
+
+
 2011-12-22  Stefano Lattarini  <stefano.lattarini <at> gmail.com>
 
 	hacking: distribute it, and mention it in the ChangeLog
diff --git a/NEWS b/NEWS
index db448a9..80ed91e 100644
--- a/NEWS
+++ b/NEWS
@@ -84,6 +84,13 @@ Bugs fixed in 1.11.0a:
     not used, `make' output no longer contains spurious backslash-only
     lines, thus once again matching what Automake did before 1.11.
 
+  - The `silent-rules' option now generates working makefiles even for
+    the uncommon `make' implementations that do not support the
+    nested-variables extension to POSIX 2008.  For such `make'
+    implementations, whether a build is silent is determined at
+    configure time, and cannot be overridden at make time with `make
+    V=0' or `make V=1'.
+
   - The AM_COND_IF macro also works if the shell expression for the conditional
     is no longer valid for the condition.
 
diff --git a/automake.in b/automake.in
index 309eade..7efb7d5 100644
--- a/automake.in
+++ b/automake.in
@@ -1161,9 +1161,12 @@ sub define_verbose_var ($$)
     my $silent_var = $pvar . '_0';
     if (option 'silent-rules')
       {
-	# Using `$V' instead of `$(V)' breaks IRIX make.
-	define_variable ($var, '$(' . $pvar . '_$(V))', INTERNAL);
-	define_variable ($pvar . '_', '$(' . $pvar . '_$(AM_DEFAULT_VERBOSITY))', INTERNAL);
+	# For typical `make's, `configure' replaces AM_V (inside @@) with $(V)
+	# and AM_DEFAULT_V (inside @@) with $(AM_DEFAULT_VERBOSITY).
+	# For strict POSIX 2008 `make's, it replaces them with 0 or 1 instead.
+	# See AM_SILENT_RULES in m4/silent.m4.
+	define_variable ($var, '$(' . $pvar . '_@'.'AM_V'.'@)', INTERNAL);
+	define_variable ($pvar . '_', '$(' . $pvar . '_@'.'AM_DEFAULT_V'.'@)', INTERNAL);
 	Automake::Variable::define ($silent_var, VAR_AUTOMAKE, '', TRUE, $val,
 				    '', INTERNAL, VAR_ASIS)
 	  if (! vardef ($silent_var, TRUE));
diff --git a/doc/automake.texi b/doc/automake.texi
index ced1b72..39884af 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -10132,18 +10132,20 @@ For portability to different @command{make} implementations, package authors
 are advised to not set the variable @code{V} inside the @file{Makefile.am}
 file, to allow the user to override the value for subdirectories as well.
 
-The current implementation of this feature relies on a non-POSIX, but in
-practice rather widely supported @file{Makefile} construct of nested
-variable expansion @samp{$(@var{var1}$(V))}.  Do not use the
-@option{silent-rules} option if your package needs to build with
-@command{make} implementations that do not support it.  The
-@option{silent-rules} option turns off warnings about recursive variable
-expansion, which are in turn enabled by @option{-Wportability}
-(@pxref{Invoking Automake}).
+The current implementation of this feature normally uses nested
+variable expansion @samp{$(@var{var1}$(V))}, a @file{Makefile} feature
+that is not required by POSIX 2008 but is widely supported in
+practice.  On the rare @command{make} implementations that do not
+support nested variable expansion, whether rules are silent is always
+determined at configure time, and cannot be overridden at make time.
+Future versions of POSIX are likely to require nested variable
+expansion, so this minor limitation should go away with time.
 
 @vindex @code{AM_V_GEN}
 @vindex @code{AM_V_at}
 @vindex @code{AM_DEFAULT_VERBOSITY}
+@vindex @code{AM_V}
+@vindex @code{AM_DEFAULT_V}
 To extend the silent mode to your own rules, you have two choices:
 
 @itemize @bullet
@@ -10159,8 +10161,8 @@ The following snippet shows how you would define your own equivalent of
 @code{AM_V_GEN}:
 
 @example
-pkg_verbose = $(pkg_verbose_$(V))
-pkg_verbose_ = $(pkg_verbose_$(AM_DEFAULT_VERBOSITY))
+pkg_verbose = $(pkg_verbose_@@AM_V@@)
+pkg_verbose_ = $(pkg_verbose_@@AM_DEFAULT_V@@)
 pkg_verbose_0 = @@echo PKG-GEN $@@;
 
 foo: foo.in
diff --git a/m4/silent.m4 b/m4/silent.m4
index 6d2a1a2..8bd931b 100644
--- a/m4/silent.m4
+++ b/m4/silent.m4
@@ -1,11 +1,11 @@
 ##                                                          -*- Autoconf -*-
-# Copyright (C) 2009  Free Software Foundation, Inc.
+# Copyright (C) 2009, 2011  Free Software Foundation, Inc.
 #
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
 # with or without modifications, as long as this notice is preserved.
 
-# serial 1
+# serial 2
 
 # AM_SILENT_RULES([DEFAULT])
 # --------------------------
@@ -20,6 +20,36 @@ yes) AM_DEFAULT_VERBOSITY=0;;
 no)  AM_DEFAULT_VERBOSITY=1;;
 *)   AM_DEFAULT_VERBOSITY=m4_if([$1], [yes], [0], [1]);;
 esac
+dnl
+dnl A few `make' implementations (e.g., NonStop OS and NextStep)
+dnl do not support nested variable expansions.
+dnl See automake bug#9928 and bug#10237.
+am_make=${MAKE-make}
+AC_CACHE_CHECK([whether $am_make supports nested variables],
+   [am_cv_make_support_nested_variables],
+   [if AS_ECHO([['TRUE=$(BAR$(V))
+BAR0=false
+BAR1=true
+V=1
+am__doit:
+	@$(TRUE)
+.PHONY: am__doit']]) | $am_make -f - >/dev/null 2>&1; then
+  am_cv_make_support_nested_variables=yes
+else
+  am_cv_make_support_nested_variables=no
+fi])
+if test $am_cv_make_support_nested_variables = yes; then
+  dnl Using `$V' instead of `$(V)' breaks IRIX make.
+  AM_V='$(V)'
+  AM_DEFAULT_V='$(AM_DEFAULT_VERBOSITY)'
+else
+  AM_V=$AM_DEFAULT_VERBOSITY
+  AM_DEFAULT_V=$AM_DEFAULT_VERBOSITY
+fi
+AC_SUBST([AM_V])dnl
+AM_SUBST_NOTMAKE([AM_V])dnl
+AC_SUBST([AM_DEFAULT_V])dnl
+AM_SUBST_NOTMAKE([AM_DEFAULT_V])dnl
 AC_SUBST([AM_DEFAULT_VERBOSITY])dnl
 AM_BACKSLASH='\'
 AC_SUBST([AM_BACKSLASH])dnl
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 5ac0e48..c1c0c83 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -759,6 +759,7 @@ silent-many-gcc.test \
 silent-many-generic.test \
 silent-lex-gcc.test \
 silent-lex-generic.test \
+silent-nested-vars.test \
 silent-yacc-gcc.test \
 silent-yacc-generic.test \
 silent-configsite.test \
diff --git a/tests/silent-nested-vars.test b/tests/silent-nested-vars.test
new file mode 100755
index 0000000..4b0fa3c
--- /dev/null
+++ b/tests/silent-nested-vars.test
@@ -0,0 +1,193 @@
+#!/bin/sh
+# Copyright (C) 2011 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# Check silent-rules mode, on 'make' implementations that do not
+# support nested variables (Bug#9928, Bug#10237).
+
+. ./defs || Exit 1
+
+set -e
+
+mkdir sub
+
+cat >>configure.in <<'EOF'
+AM_SILENT_RULES
+AM_CONDITIONAL([HAVE_NESTED_VARIABLES],
+  [expr "x$AM_V" : '.*\$' >/dev/null])
+AC_CONFIG_FILES([sub/Makefile])
+AC_PROG_CC
+AM_PROG_CC_C_O
+AC_OUTPUT
+EOF
+
+cat > Makefile.am <<'EOF'
+# Need generic and non-generic rules.
+bin_PROGRAMS = foo bar
+bar_CFLAGS = $(AM_CFLAGS)
+SUBDIRS = sub
+
+# Check that AM_V and AM_DEFAULT_V work as advertised.
+pkg_verbose = $(pkg_verbose_ <at> AM_V@)
+pkg_verbose_ = $(pkg_verbose_ <at> AM_DEFAULT_V@)
+pkg_verbose_0 = @echo PKG-GEN $@;
+
+bin_SCRIPTS = oop
+oop:
+	$(pkg_verbose)echo $@ >$@
+
+mostlyclean-local:
+	rm -f oop
+
+if HAVE_NESTED_VARIABLES
+# Check that the older form (documented in Automake 1.11) works.
+older_pkg_verbose = $(older_pkg_verbose_$(V))
+older_pkg_verbose_ = $(older_pkg_verbose_$(AM_DEFAULT_VERBOSITY))
+older_pkg_verbose_0 = @echo OLDER-PKG-GEN $@;
+
+bin_SCRIPTS += older-oop
+older-oop:
+	$(older_pkg_verbose)echo $@ >$@
+endif
+EOF
+
+cat > sub/Makefile.am <<'EOF'
+AUTOMAKE_OPTIONS = subdir-objects
+# Need generic and non-generic rules.
+bin_PROGRAMS = baz bla
+bla_CFLAGS = $(AM_CFLAGS)
+EOF
+
+cat > foo.c <<'EOF'
+int main ()
+{
+  return 0;
+}
+EOF
+cp foo.c bar.c
+cp foo.c sub/baz.c
+cp foo.c sub/bla.c
+
+cat >mymake <<'EOF'
+#! /bin/sh
+makerules=
+LC_ALL=C
+export LC_ALL
+
+case $1 in
+  -f)
+    makefile=$2
+    case $2 in
+      -) makerules=`cat` || exit ;;
+    esac ;;
+  *)
+    for makefile in makefile Makefile; do
+      test -f $makefile && break
+    done ;;
+esac
+
+if
+  nested_var_pat='^[^#]*\$([a-zA-Z0-9_]*\$'
+  case $makefile in
+    -) printf '%s\n' "$makerules" | grep "$nested_var_pat";;
+    *) grep "$nested_var_pat" $makefile;;
+  esac
+then
+  echo >&2 "mymake: $makefile contains nested variables"
+  exit 1
+fi
+
+case $makefile in
+  -) printf '%s\n' "$makerules" | $mymake_MAKE "$@";;
+  *) exec $mymake_MAKE "$@";;
+esac
+EOF
+chmod a+x mymake
+mymake_MAKE=${MAKE-make}
+export mymake_MAKE
+
+# As a sanity check, verify that `mymake' rejects Makefiles that
+# use nested variables.
+cat > Makefile <<'END'
+a = $(b$(c))
+all:
+	touch bar
+END
+./mymake && Exit 99
+mv -f Makefile foo.mk
+./mymake -f foo.mk && Exit 99
+cat foo.mk | ./mymake -f - && Exit 99
+test -f bar && Exit 99
+sed '/a =/d' foo.mk > Makefile
+./mymake && test -f bar || Exit 99
+
+$ACLOCAL
+$AUTOMAKE --add-missing
+$AUTOCONF
+
+for make in ${MAKE-make} ./mymake; do
+  ./configure --enable-silent-rules MAKE=$make >enable.out 2>&1 ||
+    { cat enable.out; Exit 1; }
+  cat enable.out
+  case $make in
+    ./mymake)
+      grep 'AM_V_CC = .*0' Makefile
+      grep 'checking whether ./mymake supports nested variables... no' \
+        enable.out
+      ;;
+  esac
+
+  $make >stdout || { cat stdout; Exit 1; }
+  cat stdout
+  $EGREP ' (-c|-o)' stdout && Exit 1
+  grep 'mv ' stdout && Exit 1
+  grep 'CC    .*foo\.' stdout
+  grep 'CC .*bar\.' stdout
+  grep 'CC .*baz\.' stdout
+  grep 'CC .*bla\.' stdout
+  grep 'CCLD .*foo' stdout
+  grep 'CCLD .*bar' stdout
+  grep 'CCLD .*baz' stdout
+  grep 'CCLD .*bla' stdout
+  grep 'PKG-GEN .*oop' stdout
+  if test $am_cv_make_support_nested_variables = yes; then
+    grep 'OLDER-PKG-GEN .*older-oop' stdout
+  fi
+  $make clean
+
+  ./configure --disable-silent-rules MAKE=$make >disable.out 2>&1 ||
+    { cat disable.out; Exit 1; }
+  cat disable.out
+  case $make in
+    ./mymake)
+      grep 'AM_V_CC = .*1' Makefile
+      grep 'checking whether ./mymake supports nested variables... no' \
+        disable.out
+      ;;
+  esac
+
+  $make >stdout || { cat stdout; Exit 1; }
+  cat stdout
+  grep ' -c' stdout
+  grep ' -o foo' stdout
+  grep 'echo .*oop' stdout
+  if test $am_cv_make_support_nested_variables = yes; then
+    grep 'echo .*older-oop' stdout
+  fi
+  $EGREP '(CC|LD) ' stdout && Exit 1
+  $make clean
+done
+
+:
-- 
1.7.6.4

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 9928 <at> debbugs.gnu.org, 10237 <at> debbugs.gnu.org, automake-patches <at> gnu.org,
	skunk <at> iskunk.org
Subject: Re: bug#9928: bug#10237: AM_SILENT_RULES does not work with NonStop
	make
Date: Fri, 23 Dec 2011 09:50:46 +0100

[adding automake-patches -- which I should have done before]

On 12/22/2011 10:56 PM, Paul Eggert wrote:
> On 12/21/11 04:21, Stefano Lattarini wrote:
>> Hi Paul, thanks for the respin.  My comments and objections are inlined.
> 
> Thanks, I have a patch updated with all those comments in mind.
> One followup:
> 
>> AM_AM_DEFAULT_VERBOSITY ?
> 
> I changed that to AM_DEFAULT_V, as that seems to fit into the naming
> convention better.
>
Thanks.

A couple of typo reports and cosmetic nits that you might fix right
away are inlined.

Apart from that, I still have some further nits and suggestions for
improvements, but I also think the patch is good enough already, and
I don't want to force you to yet another respin.  So here's the deal:
could you apply the patch *not to maint nor to master*, but to a *new*
branch (say `silent-fixes' or `silent-portability') based off of maint,
and push that new branch to the public automake repo?  We can then
address the further nits in the next days by working on that branch,
and then merge it back into maint once we're done (that will obviously
happen before 1.11.3).

> From 939ba315f5e3e5caea0513af20724c35ead86956 Mon Sep 17 00:00:00 2001
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Thu, 22 Dec 2011 13:48:54 -0800
> Subject: [PATCH] silent-rules: fallback for makes without nested vars
> 
> This fixes two problems reported for Automake (Bug#9928, Bug#10237)
> and is in response to a bug report for building coreutils on HP
> NonStop OS (Bug#10234).  The problem is that HP NonStop 'make'
> treats a line like "AM_V_CC = $(am__v_CC_$(V))" as one that
> expands a macro with the funny name am__v_CC_$(V instead of the
> desired name am__v_CC_1 or am__v_CC_0, and since the funny macro
> is not defined the line is equivalent to "AM_V_CC = )"; this
> inserts a stray ")" when $(AM_V_CC) is used, which eventually
> causes 'make' to fail.
> 
> The basic idea is that instead of generating Makefile.in lines like
> "AM_V_CC = $(am__v_CC_$(V))", we generate
> "AM_V_CC = $(am__v_CC_ <at> AM_V@)".  We then AC_SUBST $(V) for @AM_V@
> in the usual case where `make' supports nested variables,
> and substitute 1 (or 0) otherwise.  Similarly for usages like
> $(am__v_CC_$(AM_DEFAULT_VERBOSITY)).
> 
> With this change, make implementations that doesn't grasp nested
> variable expansions will still be able to run Makefiles generated
> using the silent-rules option.  They won't allow the user to
> override the make verbosity at runtime through redefinition of
> $(V) (as in "make V=0"); but this is still an improvement over not
> being able to work at all.
> 
> * NEWS: Document this.
> * automake.in (define_verbose_var): When defining the variable,
>
s/variable/variables/

> use @AM_V@ rather than $(V), and use @AM_DEFAULT_V@ rather than
> $(AM_DEFAULT_VERBOSITY).
> * doc/automake.texi (Automake silent-rules Option): Explain new system.
> * m4/silent.m4 (AM_SILENT_RULES): Check whether `make' supports
> nested variables, and substitute AM_V and AM_DEFAULT_V accordingly.
> * tests/silent-nested-vars.test: New test.
> * tests/Makefile.am (TESTS): Add it.
> ---
>  ChangeLog                     |   39 ++++++++
>  NEWS                          |    7 ++
>  automake.in                   |    9 ++-
>  doc/automake.texi             |   22 +++--
>  m4/silent.m4                  |   34 +++++++-
>  tests/Makefile.am             |    1 +
>  tests/silent-nested-vars.test |  193 +++++++++++++++++++++++++++++++++++++++++
>  7 files changed, 290 insertions(+), 15 deletions(-)
>  create mode 100755 tests/silent-nested-vars.test
> 
> diff --git a/ChangeLog b/ChangeLog
> index 26e4a2d..461dfac 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,42 @@
> +2011-12-22  Paul Eggert  <eggert <at> cs.ucla.edu>
> +
> +	silent-rules: fallback for makes without nested vars
> +
> +	This fixes two problems reported for Automake (Bug#9928, Bug#10237)
> +	and is in response to a bug report for building coreutils on HP
> +	NonStop OS (Bug#10234).  The problem is that HP NonStop 'make'
> +	treats a line like "AM_V_CC = $(am__v_CC_$(V))" as one that
> +	expands a macro with the funny name am__v_CC_$(V instead of the
> +	desired name am__v_CC_1 or am__v_CC_0, and since the funny macro
> +	is not defined the line is equivalent to "AM_V_CC = )"; this
> +	inserts a stray ")" when $(AM_V_CC) is used, which eventually
> +	causes 'make' to fail.
> +
> +	The basic idea is that instead of generating Makefile.in lines like
> +	"AM_V_CC = $(am__v_CC_$(V))", we generate
> +	"AM_V_CC = $(am__v_CC_ <at> AM_V@)".  We then AC_SUBST $(V) for @AM_V@
> +	in the usual case where `make' supports nested variables,
> +	and substitute 1 (or 0) otherwise.  Similarly for usages like
> +	$(am__v_CC_$(AM_DEFAULT_VERBOSITY)).
> +
> +	With this change, make implementations that doesn't grasp nested
> +	variable expansions will still be able to run Makefiles generated
> +	using the silent-rules option.  They won't allow the user to
> +	override the make verbosity at runtime through redefinition of
> +	$(V) (as in "make V=0"); but this is still an improvement over not
> +	being able to work at all.
> +
> +	* NEWS: Document this.
> +	* automake.in (define_verbose_var): When defining the variable,
>
s/variable/variables/

> +	use @AM_V@ rather than $(V), and use @AM_DEFAULT_V@ rather than
> +	$(AM_DEFAULT_VERBOSITY).
> +	* doc/automake.texi (Automake silent-rules Option): Explain new system.
> +	* m4/silent.m4 (AM_SILENT_RULES): Check whether `make' supports
> +	nested variables, and substitute AM_V and AM_DEFAULT_V accordingly.
> +	* tests/silent-nested-vars.test: New test.
> +	* tests/Makefile.am (TESTS): Add it.
> +
> +
>  2011-12-22  Stefano Lattarini  <stefano.lattarini <at> gmail.com>
>  
>  	hacking: distribute it, and mention it in the ChangeLog
> diff --git a/NEWS b/NEWS
> index db448a9..80ed91e 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -84,6 +84,13 @@ Bugs fixed in 1.11.0a:
>      not used, `make' output no longer contains spurious backslash-only
>      lines, thus once again matching what Automake did before 1.11.
>  
> +  - The `silent-rules' option now generates working makefiles even for
> +    the uncommon `make' implementations that do not support the
> +    nested-variables extension to POSIX 2008.  For such `make'
> +    implementations, whether a build is silent is determined at
> +    configure time, and cannot be overridden at make time with `make
> +    V=0' or `make V=1'.
> +
Better line wrapping for the last two lines?

  +    configure time, and cannot be overridden at make time with
  +    `make V=0' or `make V=1'.

No more nits from now on; quoting rest of the patch for reference.

>    - The AM_COND_IF macro also works if the shell expression for the conditional
>      is no longer valid for the condition.
>  
> diff --git a/automake.in b/automake.in
> index 309eade..7efb7d5 100644
> --- a/automake.in
> +++ b/automake.in
> @@ -1161,9 +1161,12 @@ sub define_verbose_var ($$)
>      my $silent_var = $pvar . '_0';
>      if (option 'silent-rules')
>        {
> -	# Using `$V' instead of `$(V)' breaks IRIX make.
> -	define_variable ($var, '$(' . $pvar . '_$(V))', INTERNAL);
> -	define_variable ($pvar . '_', '$(' . $pvar . '_$(AM_DEFAULT_VERBOSITY))', INTERNAL);
> +	# For typical `make's, `configure' replaces AM_V (inside @@) with $(V)
> +	# and AM_DEFAULT_V (inside @@) with $(AM_DEFAULT_VERBOSITY).
> +	# For strict POSIX 2008 `make's, it replaces them with 0 or 1 instead.
> +	# See AM_SILENT_RULES in m4/silent.m4.
> +	define_variable ($var, '$(' . $pvar . '_@'.'AM_V'.'@)', INTERNAL);
> +	define_variable ($pvar . '_', '$(' . $pvar . '_@'.'AM_DEFAULT_V'.'@)', INTERNAL);
>  	Automake::Variable::define ($silent_var, VAR_AUTOMAKE, '', TRUE, $val,
>  				    '', INTERNAL, VAR_ASIS)
>  	  if (! vardef ($silent_var, TRUE));
> diff --git a/doc/automake.texi b/doc/automake.texi
> index ced1b72..39884af 100644
> --- a/doc/automake.texi
> +++ b/doc/automake.texi
> @@ -10132,18 +10132,20 @@ For portability to different @command{make} implementations, package authors
>  are advised to not set the variable @code{V} inside the @file{Makefile.am}
>  file, to allow the user to override the value for subdirectories as well.
>  
> -The current implementation of this feature relies on a non-POSIX, but in
> -practice rather widely supported @file{Makefile} construct of nested
> -variable expansion @samp{$(@var{var1}$(V))}.  Do not use the
> -@option{silent-rules} option if your package needs to build with
> -@command{make} implementations that do not support it.  The
> -@option{silent-rules} option turns off warnings about recursive variable
> -expansion, which are in turn enabled by @option{-Wportability}
> -(@pxref{Invoking Automake}).
> +The current implementation of this feature normally uses nested
> +variable expansion @samp{$(@var{var1}$(V))}, a @file{Makefile} feature
> +that is not required by POSIX 2008 but is widely supported in
> +practice.  On the rare @command{make} implementations that do not
> +support nested variable expansion, whether rules are silent is always
> +determined at configure time, and cannot be overridden at make time.
> +Future versions of POSIX are likely to require nested variable
> +expansion, so this minor limitation should go away with time.
>  
>  @vindex @code{AM_V_GEN}
>  @vindex @code{AM_V_at}
>  @vindex @code{AM_DEFAULT_VERBOSITY}
> +@vindex @code{AM_V}
> +@vindex @code{AM_DEFAULT_V}
>  To extend the silent mode to your own rules, you have two choices:
>  
>  @itemize @bullet
> @@ -10159,8 +10161,8 @@ The following snippet shows how you would define your own equivalent of
>  @code{AM_V_GEN}:
>  
>  @example
> -pkg_verbose = $(pkg_verbose_$(V))
> -pkg_verbose_ = $(pkg_verbose_$(AM_DEFAULT_VERBOSITY))
> +pkg_verbose = $(pkg_verbose_@@AM_V@@)
> +pkg_verbose_ = $(pkg_verbose_@@AM_DEFAULT_V@@)
>  pkg_verbose_0 = @@echo PKG-GEN $@@;
>  
>  foo: foo.in
> diff --git a/m4/silent.m4 b/m4/silent.m4
> index 6d2a1a2..8bd931b 100644
> --- a/m4/silent.m4
> +++ b/m4/silent.m4
> @@ -1,11 +1,11 @@
>  ##                                                          -*- Autoconf -*-
> -# Copyright (C) 2009  Free Software Foundation, Inc.
> +# Copyright (C) 2009, 2011  Free Software Foundation, Inc.
>  #
>  # This file is free software; the Free Software Foundation
>  # gives unlimited permission to copy and/or distribute it,
>  # with or without modifications, as long as this notice is preserved.
>  
> -# serial 1
> +# serial 2
>  
>  # AM_SILENT_RULES([DEFAULT])
>  # --------------------------
> @@ -20,6 +20,36 @@ yes) AM_DEFAULT_VERBOSITY=0;;
>  no)  AM_DEFAULT_VERBOSITY=1;;
>  *)   AM_DEFAULT_VERBOSITY=m4_if([$1], [yes], [0], [1]);;
>  esac
> +dnl
> +dnl A few `make' implementations (e.g., NonStop OS and NextStep)
> +dnl do not support nested variable expansions.
> +dnl See automake bug#9928 and bug#10237.
> +am_make=${MAKE-make}
> +AC_CACHE_CHECK([whether $am_make supports nested variables],
> +   [am_cv_make_support_nested_variables],
> +   [if AS_ECHO([['TRUE=$(BAR$(V))
> +BAR0=false
> +BAR1=true
> +V=1
> +am__doit:
> +	@$(TRUE)
> +.PHONY: am__doit']]) | $am_make -f - >/dev/null 2>&1; then
> +  am_cv_make_support_nested_variables=yes
> +else
> +  am_cv_make_support_nested_variables=no
> +fi])
> +if test $am_cv_make_support_nested_variables = yes; then
> +  dnl Using `$V' instead of `$(V)' breaks IRIX make.
> +  AM_V='$(V)'
> +  AM_DEFAULT_V='$(AM_DEFAULT_VERBOSITY)'
> +else
> +  AM_V=$AM_DEFAULT_VERBOSITY
> +  AM_DEFAULT_V=$AM_DEFAULT_VERBOSITY
> +fi
> +AC_SUBST([AM_V])dnl
> +AM_SUBST_NOTMAKE([AM_V])dnl
> +AC_SUBST([AM_DEFAULT_V])dnl
> +AM_SUBST_NOTMAKE([AM_DEFAULT_V])dnl
>  AC_SUBST([AM_DEFAULT_VERBOSITY])dnl
>  AM_BACKSLASH='\'
>  AC_SUBST([AM_BACKSLASH])dnl
> diff --git a/tests/Makefile.am b/tests/Makefile.am
> index 5ac0e48..c1c0c83 100644
> --- a/tests/Makefile.am
> +++ b/tests/Makefile.am
> @@ -759,6 +759,7 @@ silent-many-gcc.test \
>  silent-many-generic.test \
>  silent-lex-gcc.test \
>  silent-lex-generic.test \
> +silent-nested-vars.test \
>  silent-yacc-gcc.test \
>  silent-yacc-generic.test \
>  silent-configsite.test \
> diff --git a/tests/silent-nested-vars.test b/tests/silent-nested-vars.test
> new file mode 100755
> index 0000000..4b0fa3c
> --- /dev/null
> +++ b/tests/silent-nested-vars.test
> @@ -0,0 +1,193 @@
> +#!/bin/sh
> +# Copyright (C) 2011 Free Software Foundation, Inc.
> +#
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 2, or (at your option)
> +# any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program.  If not, see <http://www.gnu.org/licenses/>.
> +
> +# Check silent-rules mode, on 'make' implementations that do not
> +# support nested variables (Bug#9928, Bug#10237).
> +
> +. ./defs || Exit 1
> +
> +set -e
> +
> +mkdir sub
> +
> +cat >>configure.in <<'EOF'
> +AM_SILENT_RULES
> +AM_CONDITIONAL([HAVE_NESTED_VARIABLES],
> +  [expr "x$AM_V" : '.*\$' >/dev/null])
> +AC_CONFIG_FILES([sub/Makefile])
> +AC_PROG_CC
> +AM_PROG_CC_C_O
> +AC_OUTPUT
> +EOF
> +
> +cat > Makefile.am <<'EOF'
> +# Need generic and non-generic rules.
> +bin_PROGRAMS = foo bar
> +bar_CFLAGS = $(AM_CFLAGS)
> +SUBDIRS = sub
> +
> +# Check that AM_V and AM_DEFAULT_V work as advertised.
> +pkg_verbose = $(pkg_verbose_ <at> AM_V@)
> +pkg_verbose_ = $(pkg_verbose_ <at> AM_DEFAULT_V@)
> +pkg_verbose_0 = @echo PKG-GEN $@;
> +
> +bin_SCRIPTS = oop
> +oop:
> +	$(pkg_verbose)echo $@ >$@
> +
> +mostlyclean-local:
> +	rm -f oop
> +
> +if HAVE_NESTED_VARIABLES
> +# Check that the older form (documented in Automake 1.11) works.
> +older_pkg_verbose = $(older_pkg_verbose_$(V))
> +older_pkg_verbose_ = $(older_pkg_verbose_$(AM_DEFAULT_VERBOSITY))
> +older_pkg_verbose_0 = @echo OLDER-PKG-GEN $@;
> +
> +bin_SCRIPTS += older-oop
> +older-oop:
> +	$(older_pkg_verbose)echo $@ >$@
> +endif
> +EOF
> +
> +cat > sub/Makefile.am <<'EOF'
> +AUTOMAKE_OPTIONS = subdir-objects
> +# Need generic and non-generic rules.
> +bin_PROGRAMS = baz bla
> +bla_CFLAGS = $(AM_CFLAGS)
> +EOF
> +
> +cat > foo.c <<'EOF'
> +int main ()
> +{
> +  return 0;
> +}
> +EOF
> +cp foo.c bar.c
> +cp foo.c sub/baz.c
> +cp foo.c sub/bla.c
> +
> +cat >mymake <<'EOF'
> +#! /bin/sh
> +makerules=
> +LC_ALL=C
> +export LC_ALL
> +
> +case $1 in
> +  -f)
> +    makefile=$2
> +    case $2 in
> +      -) makerules=`cat` || exit ;;
> +    esac ;;
> +  *)
> +    for makefile in makefile Makefile; do
> +      test -f $makefile && break
> +    done ;;
> +esac
> +
> +if
> +  nested_var_pat='^[^#]*\$([a-zA-Z0-9_]*\$'
> +  case $makefile in
> +    -) printf '%s\n' "$makerules" | grep "$nested_var_pat";;
> +    *) grep "$nested_var_pat" $makefile;;
> +  esac
> +then
> +  echo >&2 "mymake: $makefile contains nested variables"
> +  exit 1
> +fi
> +
> +case $makefile in
> +  -) printf '%s\n' "$makerules" | $mymake_MAKE "$@";;
> +  *) exec $mymake_MAKE "$@";;
> +esac
> +EOF
> +chmod a+x mymake
> +mymake_MAKE=${MAKE-make}
> +export mymake_MAKE
> +
> +# As a sanity check, verify that `mymake' rejects Makefiles that
> +# use nested variables.
> +cat > Makefile <<'END'
> +a = $(b$(c))
> +all:
> +	touch bar
> +END
> +./mymake && Exit 99
> +mv -f Makefile foo.mk
> +./mymake -f foo.mk && Exit 99
> +cat foo.mk | ./mymake -f - && Exit 99
> +test -f bar && Exit 99
> +sed '/a =/d' foo.mk > Makefile
> +./mymake && test -f bar || Exit 99
> +
> +$ACLOCAL
> +$AUTOMAKE --add-missing
> +$AUTOCONF
> +
> +for make in ${MAKE-make} ./mymake; do
> +  ./configure --enable-silent-rules MAKE=$make >enable.out 2>&1 ||
> +    { cat enable.out; Exit 1; }
> +  cat enable.out
> +  case $make in
> +    ./mymake)
> +      grep 'AM_V_CC = .*0' Makefile
> +      grep 'checking whether ./mymake supports nested variables... no' \
> +        enable.out
> +      ;;
> +  esac
> +
> +  $make >stdout || { cat stdout; Exit 1; }
> +  cat stdout
> +  $EGREP ' (-c|-o)' stdout && Exit 1
> +  grep 'mv ' stdout && Exit 1
> +  grep 'CC    .*foo\.' stdout
> +  grep 'CC .*bar\.' stdout
> +  grep 'CC .*baz\.' stdout
> +  grep 'CC .*bla\.' stdout
> +  grep 'CCLD .*foo' stdout
> +  grep 'CCLD .*bar' stdout
> +  grep 'CCLD .*baz' stdout
> +  grep 'CCLD .*bla' stdout
> +  grep 'PKG-GEN .*oop' stdout
> +  if test $am_cv_make_support_nested_variables = yes; then
> +    grep 'OLDER-PKG-GEN .*older-oop' stdout
> +  fi
> +  $make clean
> +
> +  ./configure --disable-silent-rules MAKE=$make >disable.out 2>&1 ||
> +    { cat disable.out; Exit 1; }
> +  cat disable.out
> +  case $make in
> +    ./mymake)
> +      grep 'AM_V_CC = .*1' Makefile
> +      grep 'checking whether ./mymake supports nested variables... no' \
> +        disable.out
> +      ;;
> +  esac
> +
> +  $make >stdout || { cat stdout; Exit 1; }
> +  cat stdout
> +  grep ' -c' stdout
> +  grep ' -o foo' stdout
> +  grep 'echo .*oop' stdout
> +  if test $am_cv_make_support_nested_variables = yes; then
> +    grep 'echo .*older-oop' stdout
> +  fi
> +  $EGREP '(CC|LD) ' stdout && Exit 1
> +  $make clean
> +done
> +
> +:

Thanks,
  Stefano

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 9928 <at> debbugs.gnu.org, 10237 <at> debbugs.gnu.org, automake-patches <at> gnu.org,
	skunk <at> iskunk.org
Subject: Re: bug#9928: bug#10237: AM_SILENT_RULES does not work with NonStop
	make
Date: Sun, 25 Dec 2011 10:04:59 -0800

On 12/23/11 00:50, Stefano Lattarini wrote:
> could you apply the patch *not to maint nor to master*, but to a *new*
> branch (say `silent-fixes' or `silent-portability') based off of maint,
> and push that new branch to the public automake repo?

OK, done, as 'silent-fixes', with your recent nit-fixes applied.

Here's a URL for anyone else who wants to follow along:

http://git.savannah.gnu.org/cgit/automake.git/log/?h=silent-fixes

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 9928 <at> debbugs.gnu.org, 10237 <at> debbugs.gnu.org, automake-patches <at> gnu.org,
	skunk <at> iskunk.org
Subject: Re: bug#10237: bug#9928: bug#10237: AM_SILENT_RULES does not work
	with NonStop make
Date: Mon, 26 Dec 2011 18:42:35 +0100

[Message part 1 (text/plain, inline)]

tags 10237 + patch
tags 9928 + patch
thanks

On 12/25/2011 07:04 PM, Paul Eggert wrote:
> On 12/23/11 00:50, Stefano Lattarini wrote:
>> could you apply the patch *not to maint nor to master*, but to a *new*
>> branch (say `silent-fixes' or `silent-portability') based off of maint,
>> and push that new branch to the public automake repo?
> 
> OK, done, as 'silent-fixes', with your recent nit-fixes applied.
>
> Here's a URL for anyone else who wants to follow along:
> 
> http://git.savannah.gnu.org/cgit/automake.git/log/?h=silent-fixes
> 
Thanks.  And here is the follow-up tweaking for the test cases I had
promised.  I will push in a couple of days if there is no objection.

Thanks,
  Stefano

[0001-tests-tweak-tests-on-silent-rules-for-makes-without-.patch (text/x-diff, attachment)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 9928 <at> debbugs.gnu.org, 10237 <at> debbugs.gnu.org, automake-patches <at> gnu.org,
	skunk <at> iskunk.org
Subject: Re: bug#10237: bug#9928: bug#10237: AM_SILENT_RULES does not work
	with NonStop make
Date: Mon, 26 Dec 2011 10:09:15 -0800

On 12/26/11 09:42, Stefano Lattarini wrote:
> And here is the follow-up tweaking for the test cases I had
> promised.  I will push in a couple of days if there is no objection.

Thanks, that looks good to me; please push it as soon as you like.

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 9928 <at> debbugs.gnu.org, 10237 <at> debbugs.gnu.org, automake-patches <at> gnu.org,
	skunk <at> iskunk.org
Subject: Re: AM_SILENT_RULES does not work with NonStop make
Date: Mon, 26 Dec 2011 22:35:27 +0100

On 12/26/2011 07:09 PM, Paul Eggert wrote:
> On 12/26/11 09:42, Stefano Lattarini wrote:
>> And here is the follow-up tweaking for the test cases I had
>> promised.  I will push in a couple of days if there is no objection.
> 
> Thanks, that looks good to me; please push it as soon as you like.
>
Done.

I plan to merge the 'silent-fixes' branch back into maint as soon as I (or
someone else ;-) have done more extensive testsuite runs and/or on-field
testing on non-Linux systems (*BSD and Solaris at least, hopefully also
Cygwin or MinGW).

If someone could also test the patches on a NonStop and/or NextStep system,
that would be great.

Thanks,
  Stefano

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 9928 <at> debbugs.gnu.org, 10237 <at> debbugs.gnu.org, automake-patches <at> gnu.org,
	skunk <at> iskunk.org
Subject: Re: AM_SILENT_RULES does not work with NonStop make
Date: Wed, 28 Dec 2011 12:08:44 -0800

On 12/26/11 13:35, Stefano Lattarini wrote:
> testing on non-Linux systems (*BSD and Solaris at least, hopefully also
> Cygwin or MinGW).

I tested it on Solaris 8 and that test worked fine.
I used Autoconf 2.63, GNU m4 1.4.13, and the system-supplied 'make'.

Some of the other tests failed, e.g., because I didn't have
Fortran installed, but I didn't investigate them; it hardly
seems worth the trouble for such an old system.

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 9928 <at> debbugs.gnu.org, 10237 <at> debbugs.gnu.org, automake-patches <at> gnu.org,
	skunk <at> iskunk.org
Subject: Re: bug#9928: AM_SILENT_RULES does not work with NonStop make
Date: Wed, 28 Dec 2011 21:19:23 +0100

Hi Paul.

On 12/28/2011 09:08 PM, Paul Eggert wrote:
> On 12/26/11 13:35, Stefano Lattarini wrote:
>> testing on non-Linux systems (*BSD and Solaris at least, hopefully also
>> Cygwin or MinGW).
> 
> I tested it on Solaris 8 and that test worked fine.
> I used Autoconf 2.63, GNU m4 1.4.13, and the system-supplied 'make'.
> 
> Some of the other tests failed, e.g., because I didn't have
> Fortran installed, but I didn't investigate them; it hardly
> seems worth the trouble for such an old system.
> 
> 
I did some testing on Debian unstable, Solaris 10, NetBSD 5.1 and Cygwin 1.5 (in
part by running the relevant test cases from the automake testsuite, in part
trying out the build system of GNU coreutils).   Everything seems fine so far.
I want to do some small improvements to the documentation, then I say we are
ready to merge the 'silent-fixes' branch into maint.

Regards,
  Stefano

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 10237-done <at> debbugs.gnu.org, automake-patches <at> gnu.org,
	9928-done <at> debbugs.gnu.org, skunk <at> iskunk.org
Subject: Re: bug#10237: bug#9928: AM_SILENT_RULES does not work with NonStop
	make
Date: Fri, 30 Dec 2011 13:50:04 +0100

On 12/28/2011 09:19 PM, Stefano Lattarini wrote:
>
> I did some testing on Debian unstable, Solaris 10, NetBSD 5.1 and Cygwin 1.5 (in
> part by running the relevant test cases from the automake testsuite, in part
> trying out the build system of GNU coreutils).   Everything seems fine so far.
> I want to do some small improvements to the documentation, then I say we are
> ready to merge the 'silent-fixes' branch into maint.
>
I've just re-read Paul's changes to the manual, and on a second thought, I think
they are definitely good enough as they are.  I've thus merged the 'silent-fixes'
branch into maint, and pushed.  I'm thus closing the bugs #9928 and #10237.

Thanks,
  Stefano

Previous Next

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