[bug #60217] Handling of V=n build flag inflexible

[Dave]

Follow-up Comment #1, bug #60217 (project groff):

Hi Michael, thanks for the report!

This framework appears to originate not in groff but in automake.  am__v_P_0
and am__v_P_1 are set in the _generated_ Makefile, but appear nowhere in the
source Makefile.am
<http://git.savannah.gnu.org/cgit/groff.git/tree/Makefile.am> nor any other
files in the groff tree.

The automake documentation node
http://www.gnu.org/software/automake/manual/html_node/Automake-Silent-Rules.html
explains how to have "make" use silent rules (as groff does): set
AM_SILENT_RULES([yes]) in configure.ac.  Groff's configure.ac
<http://git.savannah.gnu.org/cgit/groff.git/tree/configure.ac> does exactly
this.  Everything else about the verbosity level, automake appears to handle.

So it seems like the right fix is to have automake itself allow V to be values
other than 0 or 1.  If your build environment depends on this, you'll run into
this problem sooner or later with other packages that use automake, so
upstream seems like the best place to handle this.

In fact, this very request was filed in the automake bug tracker in 2015:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20077 (also by someone using
OpenWrt).  Earlier this year, one of the developers pushed back a little based
on the fact that the current behavior has been documented for some time now,
but this seems like a weak argument to me: allowing _more_ values for V than
is currently documented does nothing to invalidate any previous use of the
documented behavior.  That is, allowing V to be zero or nonzero still supports
all previous use of this variable being set to 0 or 1.

So my suggestion is to make that argument in that bug report.  (I'm unfamiliar
with their bug tracker, but it appears that new comments are added by emailing
20077 <at> debbugs.gnu.org rather than through a web interface.)  It's also
useful to post there to let them know multiple people are experiencing the
same problem, as so far there seems to be just the one user who has written
about it.

I leave it to someone more familiar with the groff build system to determine
whether the workaround cited in that bug report is appropriate to integrate
into groff.  But this would solve your problem for only one package, where
fixing it within automake would solve it globally.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60217>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/