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/
