* 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
On Mon, Mar 21, 2011 at 8:28 AM, Karl Berry wrote:
> 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 d
Hi Jack,
New automake options? Something like:
I like my idea of a variable better :).
Seems simpler/less intrusive/more general.
Best,
k
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 problem
On Sun, Mar 20, 2011 at 10:53 PM, Ralf Wildenhues
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
Hi Karl,
thanks for the bug report.
* Karl Berry wrote on Sat, Mar 19, 2011 at 12:33:14AM CET:
> http://comments.gmane.org/gmane.comp.sysutils.automake.general/10304
>
> I suggest that the workaround Ralf suggests there -- an empty make rule
> for dvi: -- be explicitly documented. Another (ofte
