bug#20077: Allow more V= values for verbose output

[Karl Berry]

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