GNU bug report logs - #8289
distcheck and make dvi

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8289 in the body.
You can then email your comments to 8289 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: karl <at> freefriends.org (Karl Berry)
To: bug-automake <at> gnu.org
Subject: distcheck and make dvi
Date: Fri, 18 Mar 2011 23:33:14 GMT

Hi Ralf and all,

make distcheck runs make dvi.  If an author has only made .pdf's with
images, this will cause a surprising error that .eps files are missing.
(Someone just wrote me about this.)

I see the issue has been noted before, e.g.:
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 (often preferable) option
is to create and distribute the .eps files, of course.

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.

Thanks,
Karl

Message #8 received at 8289 <at> debbugs.gnu.org (full text, mbox):

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Karl Berry <karl <at> freefriends.org>
Cc: 8289 <at> debbugs.gnu.org
Subject: Re: bug#8289: distcheck and make dvi
Date: Sun, 20 Mar 2011 12:53:44 +0100

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 (often preferable) option
> is to create and distribute the .eps files, of course.

Agreed on all accounts.  However, there are cases where dvi output just
isn't feasible in practice.

Reuben Thomas has suggested more general latex support in bug 8099,
which also touches this area.

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

Thanks,
Ralf

Message #11 received at 8289 <at> debbugs.gnu.org (full text, mbox):

From: Jack Kelly <jack <at> jackkelly.name>
To: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
Cc: 8289 <at> debbugs.gnu.org, Karl Berry <karl <at> freefriends.org>
Subject: Re: bug#8289: distcheck and make dvi
Date: Mon, 21 Mar 2011 05:02:27 +1100

On Sun, Mar 20, 2011 at 10:53 PM, Ralf Wildenhues
<Ralf.Wildenhues <at> 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

Message #14 received at 8289 <at> debbugs.gnu.org (full text, mbox):

From: karl <at> freefriends.org (Karl Berry)
To: 8289 <at> debbugs.gnu.org
Subject: Re: bug#8289: distcheck and make dvi
Date: Sun, 20 Mar 2011 21:28:59 GMT

    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

Message #17 received at 8289 <at> debbugs.gnu.org (full text, mbox):

From: Jack Kelly <jack <at> jackkelly.name>
To: Karl Berry <karl <at> freefriends.org>
Cc: 8289 <at> debbugs.gnu.org
Subject: Re: bug#8289: distcheck and make dvi
Date: Mon, 21 Mar 2011 09:34:07 +1100

On Mon, Mar 21, 2011 at 8:28 AM, Karl Berry <karl <at> freefriends.org> 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 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.

New automake options? Something like:

    AM_INIT_AUTOMAKE([foreign distcheck-doc-pdf no-distcheck-doc-dvi])

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

Good to know.

-- Jack

Message #20 received at 8289 <at> debbugs.gnu.org (full text, mbox):

From: karl <at> freefriends.org (Karl Berry)
To: jack <at> jackkelly.name
Cc: 8289 <at> debbugs.gnu.org
Subject: Re: bug#8289: distcheck and make dvi
Date: Sun, 20 Mar 2011 22:35:27 GMT

Hi Jack,

    New automake options? Something like:

I like my idea of a variable better :).
Seems simpler/less intrusive/more general.

Best,
k

Message #23 received at 8289 <at> debbugs.gnu.org (full text, mbox):

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Karl Berry <karl <at> freefriends.org>
Cc: 8289 <at> debbugs.gnu.org
Subject: Re: bug#8289: distcheck and make dvi
Date: Mon, 21 Mar 2011 04:51:30 +0100

* 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

Message #26 received at 8289 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: 8289 <at> debbugs.gnu.org
Subject: Re: bug#8289: distcheck and make dvi
Date: Sun, 17 May 2020 10:43:28 -0600

[Message part 1 (text/plain, inline)]

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 (application/octet-stream, attachment)]

Message #29 received at 8289 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Karl Berry <karl <at> freefriends.org>
Cc: 8289 <at> debbugs.gnu.org
Subject: Re: bug#8289: distcheck and make dvi
Date: Fri, 22 May 2020 18:23:17 -0700

On Sun, May 17, 2020 at 9:44 AM Karl Berry <karl <at> freefriends.org> 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.

Message #34 received at 8289-done <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: 8289-done <at> debbugs.gnu.org
Subject: Re: bug#8289: distcheck and make dvi
Date: Mon, 25 May 2020 19:31:15 -0600

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.