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

Previous Next

Full log

View this message in rfc822 format

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

Previous Next

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