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