bugGNU roff - Bugs: bug #60217, Handling of V=n build flag...

 
 

bug #60217: Handling of V=n build flag inflexible

Submitter:  W. Michael Petullo <flyn>
Submitted:  Fri 12 Mar 2021 05:15:25 PM UTC
   
 
Category:  Core Severity:  3 - Normal
Item Group:  Build/Installation Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 14 Jul 2022 01:33:04 PM UTC, comment #1: 

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

Dave <barx>
Group Member
Fri 12 Mar 2021 05:15:25 PM UTC, original submission:  

I am using GNU troff 1.22.4.

The build process for GNU troff allows the use of "V" to enable or disable a verbose build. The process supports only V=0 or V=1. This is seen in the Makefile, which contains the definitions of am__v_P_0 and am__v_P_1.

I am trying to build GNU troff for OpenWrt, and the OpenWrt build process, which surrounds the GNU troff build process in my case, might set V to something like 99 or another value other than 0 or 1. This breaks the build of GNU troff.

Could we allow V to be zero or non-zero instead of zero or one?

W. Michael Petullo <flyn>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by barx (Posted a comment)
  • -email is unavailable- added by flyn (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code