GNU bug report logs - #20077
automake / silent-rules / $(V) when V= not set to '' or 1 or 2 (e.g. V=1234)

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 20077 in the body.
You can then email your comments to 20077 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: Mirko Vogt <automake <at> nanl.de>
To: bug-automake <at> gnu.org
Subject: automake / silent-rules / $(V)
Date: Wed, 11 Mar 2015 02:06:40 +0100

I just stumbled across an issue where a project fails to compile using
automake and silent-rules with $V being set to sth. else other than '1'
or '0'.

This is because of the following resulting Makefile code when using
silent rules:

AM_V_P = $(am__v_P_$(V))
am__v_P_ = $(am__v_P_$(AM_DEFAULT_VERBOSITY))
am__v_P_0 = false
am__v_P_1 = :

This breaks builds in environments such as e.g. the cross-compiling
framework OpenWrt - which also uses $(V), however with values other than
1/0 (e.g. V=99, V={c,w,s}, etc.).

The way automake behaves here it claims that variable for its exclusive
use. I don't mind automake using $(V), however if using such generic
variable names, please don't make projects fail when $(V) is set to
something other than 1 or 0.

My proposal would be to enable verbose output, if $(V) is set to
anything but '0' and to disable otherwise ($V is unset / set to '0').

Cheers

  mirko

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

From: Pavel Raiskup <praiskup <at> redhat.com>
To: bug-automake <at> gnu.org
Cc: Mirko Vogt <automake <at> nanl.de>, 20077 <at> debbugs.gnu.org
Subject: Re: bug#20077: automake / silent-rules / $(V)
Date: Fri, 27 Mar 2015 17:45:30 +0100

On Wednesday 11 of March 2015 02:06:40 Mirko Vogt wrote:
> I just stumbled across an issue where a project fails to compile using
> automake and silent-rules with $V being set to sth. else other than '1'
> or '0'.
> 
> This is because of the following resulting Makefile code when using
> silent rules:
> 
> AM_V_P = $(am__v_P_$(V))
> am__v_P_ = $(am__v_P_$(AM_DEFAULT_VERBOSITY))
> am__v_P_0 = false
> am__v_P_1 = :
> 
> This breaks builds in environments such as e.g. the cross-compiling
> framework OpenWrt - which also uses $(V), however with values other than
> 1/0 (e.g. V=99, V={c,w,s}, etc.).

Its not ideal (dirty), but you can work-around that by specifying
'make AM_V_P=true' explicitly.  Or the project itself can do something
like

  $ cat Makefile.am | grep ^AM_V_P
  AM_V_P = test x0 = "x$(V)"

.. when the project is known to use $V for its own purposes.

> The way automake behaves here it claims that variable for its exclusive
> use. I don't mind automake using $(V), however if using such generic
> variable names, please don't make projects fail when $(V) is set to
> something other than 1 or 0.
> 
> My proposal would be to enable verbose output, if $(V) is set to
> anything but '0' and to disable otherwise ($V is unset / set to '0').

That would probably require changing the semantics of $AM_V_P a bit, as it
now was always ':' or 'false'.  But could be worth having fixed somehow.

Pavel

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

From: Mike Frysinger <vapier <at> gentoo.org>
To: Pavel Raiskup <praiskup <at> redhat.com>
Cc: Mirko Vogt <automake <at> nanl.de>, 20077 <at> debbugs.gnu.org
Subject: Re: bug#20077: automake / silent-rules / $(V)
Date: Sun, 20 Feb 2022 19:52:03 +0000 (UTC)

On Fri, 27 Mar 2015 17:45:30 +0100, Pavel Raiskup wrote:
> On Wednesday 11 of March 2015 02:06:40 Mirko Vogt wrote:
> > I just stumbled across an issue where a project fails to compile using
> > automake and silent-rules with $V being set to sth. else other than '1'
> > or '0'.
> > 
> > This is because of the following resulting Makefile code when using
> > silent rules:
> > 
> > AM_V_P = $(am__v_P_$(V))
> > am__v_P_ = $(am__v_P_$(AM_DEFAULT_VERBOSITY))
> > am__v_P_0 = false
> > am__v_P_1 = :
> > 
> > This breaks builds in environments such as e.g. the cross-compiling
> > framework OpenWrt - which also uses $(V), however with values other than
> > 1/0 (e.g. V=99, V={c,w,s}, etc.).
>
> Its not ideal (dirty), but you can work-around that by specifying
> 'make AM_V_P=true' explicitly.  Or the project itself can do something
> like
>
>   $ cat Makefile.am | grep ^AM_V_P
>   AM_V_P = test x0 = "x$(V)"
>
> .. when the project is known to use $V for its own purposes.

GNU Make supports:
am__v_P_$(V) = $(am__v_P_$(AM_DEFAULT_VERBOSITY))

`make V='asldfj aksdfj lajsdf'` still works with this.

but i don't know how portable this is.  might be as portable as recursive
make variables in general ?

> > The way automake behaves here it claims that variable for its exclusive
> > use. I don't mind automake using $(V), however if using such generic
> > variable names, please don't make projects fail when $(V) is set to
> > something other than 1 or 0.
> > 
> > My proposal would be to enable verbose output, if $(V) is set to
> > anything but '0' and to disable otherwise ($V is unset / set to '0').
>
> That would probably require changing the semantics of $AM_V_P a bit, as it
> now was always ':' or 'false'.  But could be worth having fixed somehow.

i don't think changing AM_V_P semantics is feasible.  it's documented in the
manual as having this behavior and has since automake-1.13 (for ~10 years).
this variable is meant to be used by code written by users, not an internal
Automake setting.
-mike

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

From: Mirko Vogt <automake <at> nanl.de>
To: Mike Frysinger <vapier <at> gentoo.org>, Pavel Raiskup <praiskup <at> redhat.com>
Cc: Mirko Vogt <automake <at> nanl.de>, 20077 <at> debbugs.gnu.org
Subject: Re: bug#20077: automake / silent-rules / $(V)
Date: Sun, 20 Feb 2022 21:57:12 +0000

On 20.02.22 19:52, Mike Frysinger wrote:
> i don't think changing AM_V_P semantics is feasible.  it's documented in the
> manual as having this behavior and has since automake-1.13 (for ~10 years).

Well, that might be the case by now. When I filed that 7 years ago it 
wasn't, though.

> this variable is meant to be used by code written by users, not an
> internal Automake setting.

Which is exactly my point.

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

From: Bogdan <bogdro_rep <at> gmx.us>
To: automake-patches <at> gnu.org
Subject: [bug#20077] Allow more V= values for verbose output
Date: Sat, 31 Dec 2022 20:21:00 +0100

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

Hello, Automakers!

My last patch for now, this time for 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20077:

- if $(V) is empty, use default verbosity,
- if $(V) = 0, be silent,
- if $(V) is neither empty nor 0, be verbose (not only with V=1, but 
e.g. V=99).

Yes, requires some shell, but just like other stuff.

Note that this just switches verbosity off and on, doesn't pay any 
attention if the user would want e.g. more verbosity with V=99 than 
with V=1.

Regards,
Bogdan Drozdowski


-- 
Regards - Bogdan ('bogdro') D.                 (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):    http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org

[automake-verbose-more-values-mail.diff (text/x-patch, attachment)]

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

From: Karl Berry <karl <at> freefriends.org>
To: automake <at> nanl.de
Cc: bug-automake <at> gnu.org, automake-patches <at> gnu.org
Subject: Re: bug#20077: Allow more V= values for verbose output
Date: Tue, 27 Jun 2023 19:14:34 -0600

    bd> My last patch for now, this time for 
    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20077

Thanks Bogdan, but $(shell) is a GNU make extension. It can't be used in
Automake's generated Makefile[.in]s.

    mf> GNU Make supports:
    mf> am__v_P_$(V) = $(am__v_P_$(AM_DEFAULT_VERBOSITY))

Thanks Mike, but I expect that variable expansion on the lhs of make
assignments is also not portable enough.

Unfortunately, I don't think it is possible to fix this without inducing
too much incompatibility. A generated Makefile currently contains:

  AM_V_P = $(am__v_P_$(V))
  am__v_P_ = $(am__v_P_$(AM_DEFAULT_VERBOSITY))
  am__v_P_0 = false
  am__v_P_1 = :

In order to allow any value for V, its value presumably has to be
reduced to 0 or 1. So the Makefile would contain something like:

  AM_V_P_zero_or_one = <something reducing $V to 0 or 1>
  AM_V_P = $(am__v_P_$(AM_V_P_zero_or_one))
  ...

instead of using $(V) directly.

But ... as far as I can see, this reduction would have to be done at
make time, as in Bogdan's patch. A regular shell expression will not
work because of the way $(AM_V_P) and the other variables are used. I
don't believe it is possible without extensions to make which we cannot
assume.

Meanwhile, Pavel's workaround of setting AM_V_P=true (or similar),
while not pretty, seems like it gets the job done, at least making it
possible to include OpenWRT or other packages that use V differently.
(Evidently there aren't many of them, since I don't think there's ever
been any other report of this problem.)

The Automake manual also documents that users can write:
        if $(AM_V_P); then set -x; else echo " GEN   [headers]"; fi; \
so AM_V_P can't be anything complicated, i.e., requiring quoting.

Thus, I have pushed a change to the manual discussing the issue,
since it seems we can't do better :(.  --thanks to all, karl.

-----------------------------------------------------------------------------
doc: discuss workaround for V=99 failing.

In response to https://bugs.gnu.org/20077.

* doc/automake.texi (Tricks For Silencing Make): state and discuss
workarounds for the limitation of $(V) only being settable to 0 or 1.
diff --git a/doc/automake.texi b/doc/automake.texi
index 72398adf9..a56e7f8ee 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -11368,11 +11368,21 @@ run time:
 Passing @option{--enable-silent-rules} to @command{configure} will cause
 build rules to be less verbose; the option @option{--disable-silent-rules}
 will cause normal verbose output.
+
 @item
 @vindex @code{V}
 At @command{make} run time, the default chosen at @command{configure}
 time may be overridden: @code{make V=1} will produce verbose output,
 @code{make V=0} less verbose output.
+
+Unfortunately, if @code{V} is assigned a value other than 0 or 1,
+errors will result. This is problematic when a third-party program or
+library is built in the same tree and also uses the make variable
+@code{V}, with different values. The best workaround is probably to
+set @code{AM_V_P=true} (or similar), either on the make command line
+or in the @code{V}-using project's @code{Makefile.am}. For more
+discussion:
+@url{https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20077}.
 @end itemize

 @cindex default verbosity for silent rules
@@ -11392,19 +11402,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: is there 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.
-
-To work at its best, the current implementation of this feature normally
-uses nested variable expansion @samp{$(@var{var1}$(V))}, a @file{Makefile}
+To work best, 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.
+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}
@@ -11414,7 +11419,6 @@ limitation should go away with time.
 To extend the silent mode to your own rules, you have a few choices:

 @itemize @bullet
-
 @item
 You can use the predefined variable @code{AM_V_GEN} as a prefix to
 commands that should output a status line in silent mode, and
@@ -11426,7 +11430,7 @@ will expand to the empty string.
 You can silence a recipe unconditionally with @code{@@}, and then use
 the predefined variable @code{AM_V_P} to know whether make is being run
 in silent or verbose mode; adjust the verbose information your recipe
-displays accordingly:
+displays accordingly. For example:

 @example
 generate-headers:
@@ -11436,10 +11440,14 @@ generate-headers:
         rm -f $$headers && generate-header --flags $$headers
 @end example

+@code{AM_V_P} is (must) always set to a simple command, not needing
+shell quoting, typically either @code{:} or @code{true} or
+@code{false}.
+
 @item
 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
-@code{AM_V_GEN}:
+@code{AM_V_GEN}, say a string @samp{PKG-GEN}:

 @example
 pkg_verbose = $(pkg_verbose_@@AM_V@@)

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

From: Karl Berry <karl <at> freefriends.org>
To: 20077-done <at> debbugs.gnu.org
Date: Wed, 28 Jun 2023 15:54:55 -0600

Previous Next

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