bug#8289: distcheck and make dvi
bug#8289: distcheck and make dvi
On Sun, May 17, 2020 at 9:44 AM Karl Berry wrote: > I've attempted to construct a patch [attached] following my own > suggestion :), to create a new variable to allow overriding the "make > dvi" which is done as part of distcheck with another target. I named the > variable AM_DISTCHECK_DVI_TARGET (if something else seems better, > fine). The actual functional change is one line, in distdir.am: > > - && $(MAKE) $(AM_MAKEFLAGS) dvi \ > + && $(MAKE) $(AM_MAKEFLAGS) $(AM_DISTCHECK_DVI_TARGET) \ > > All else is overhead. My biggest question is about naming. I simply > AM_DISTCHECK_DVI_TARGET = dvi > for the default also in distdir.am. This necessitated adding it to the > list of AM_* variables allowed to be defined, in Variable.pm: > - (AM_MAKEINFOHTMLFLAGS => 1, > + (AM_DISTCHECK_DVI_TARGET => 1, > + AM_MAKEINFOHTMLFLAGS => 1, > > > Would it be better to use a separate variable, like > am__distcheck_dvi_target? But then how to know if the user has defined > AM_DISTCHECK_DVI_TARGET? > > Of course any and all comments welcome ... Jim? Anyone? --thanks, karl. Hi Karl, That looks fine to me. Sorry it took so long to reply.
bug#8289: distcheck and make dvi
I've attempted to construct a patch [attached] following my own suggestion :), to create a new variable to allow overriding the "make dvi" which is done as part of distcheck with another target. I named the variable AM_DISTCHECK_DVI_TARGET (if something else seems better, fine). The actual functional change is one line, in distdir.am: - && $(MAKE) $(AM_MAKEFLAGS) dvi \ + && $(MAKE) $(AM_MAKEFLAGS) $(AM_DISTCHECK_DVI_TARGET) \ All else is overhead. My biggest question is about naming. I simply AM_DISTCHECK_DVI_TARGET = dvi for the default also in distdir.am. This necessitated adding it to the list of AM_* variables allowed to be defined, in Variable.pm: - (AM_MAKEINFOHTMLFLAGS => 1, + (AM_DISTCHECK_DVI_TARGET => 1, + AM_MAKEINFOHTMLFLAGS => 1, Would it be better to use a separate variable, like am__distcheck_dvi_target? But then how to know if the user has defined AM_DISTCHECK_DVI_TARGET? Of course any and all comments welcome ... Jim? Anyone? --thanks, karl. distcheck-dvi.patch Description: Binary data
bug#8289: distcheck and make dvi
On Sun, Mar 20, 2011 at 10:53 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Another possible change, in addition to messing with the documentation, would be to make the dvi a variable that such non-dvi-generating people can override with pdf if they wish. Then they could get the benefit of the check in a clean way without forcing .eps. Or maybe dvi: pdf would have the same effect? I'm not sure. Well, 'dvi: pdf' might help the distcheck to succeed, but generally, if I run 'make dvi' then what I'd like is DVI not PDF output. The latter is not convertible into the former. Enhancing distcheck to just not bother checking dvi output and rather test PDF output seems like another good alternative. Not only does this feel like a hack, but I'd worry that it might violate the GNU coding standards, to which automake-generated makefiles are meant to comply? -- Jack
bug#8289: distcheck and make dvi
However, there are cases where dvi output just isn't feasible in practice. Yep. Therein lies the essence of the problem. not bother checking dvi output and rather test PDF output seems like another good alternative. I can't agree with that. That's trading DVI-generation problems for PDF-generation problems. Believe me, there will be just as many if not more. Any manual which has *only* eps files, for starters. All together, for a general fix, my suggestion is to simply replace the hardwired dvi string with a new variable name, like $(AM_DISTCHECK_DOC) or some such (no idea if that's a reasonable name, but you get the idea), which defaults to dvi and which users can override either with pdf or with some no-op target. Which in turn would need to be created/documented if one doesn't exist already. How does that sound? jack violate the GNU coding standards, to which automake-generated makefiles are meant to comply? The dvi: pdf kludge was a user override. The coding standards aren't an issue in that case. Thanks, k
bug#8289: distcheck and make dvi
Hi Jack, New automake options? Something like: I like my idea of a variable better :). Seems simpler/less intrusive/more general. Best, k
bug#8289: distcheck and make dvi
* Karl Berry wrote on Sun, Mar 20, 2011 at 10:28:59PM CET: not bother checking dvi output and rather test PDF output seems like another good alternative. I can't agree with that. That's trading DVI-generation problems for PDF-generation problems. Believe me, there will be just as many if not more. Any manual which has *only* eps files, for starters. Right, I'm on the same page as you here: such a trade should be at the developer's discretion. All together, for a general fix, my suggestion is to simply replace the hardwired dvi string with a new variable name, like $(AM_DISTCHECK_DOC) or some such (no idea if that's a reasonable name, but you get the idea), which defaults to dvi and which users can override either with pdf or with some no-op target. Which in turn would need to be created/documented if one doesn't exist already. Something like that sounds sensible. Incidentally, Stefano already has a pending patch for some distcheck generalizations using variables; the change for this PR could look to use similar style. Cheers, Ralf
