[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fwd: --add-missing]

From: Derek R. Price
Subject: Re: [Fwd: --add-missing]
Date: Mon, 18 Dec 2000 12:30:22 -0500

Tom Tromey wrote:

> >>>>> "Derek" == Derek R Price <address@hidden> writes:
> >> Me too.  But the point is that GNU packages are supposed to ship
> >> with texinfo.tex.
> Derek> Is there a web page somewhere with this standard on it?  I
> Derek> browsed briefly but I haven't been able to locate one.
> It is in the GNU Coding Standards.  I know these are on the web but
> offhand I don't know where.  Here is the text from the standard:
>        Include in your distribution a copy of the `texinfo.tex' you used to
>     test print any `*.texinfo' or `*.texi' files.
> For me appears in /usr/info/.

Okay, found this file.  Seems not to mention some of the other files automake
looks for like AUTHORS & COPYING, however.

> >> I'm reluctant to rely on kpsewhich.  What if we changed makeinfo to
> >> have an option to print the path to texinfo.tex?
> Derek> What's the difference?  Who maintains makeinfo?
> makeinfo is a GNU program.  Offhand I don't know who maintains it.

Hmm.  Seems to be distributed with GNU texinfo, though.  Not sure that makes a

> Derek> The makeinfo on my system seems to have been installed with my
> Derek> texinfo package anyhow, the same place kpsewhich came from.
> For me, kpsewhich is from the tetex package.  I'm fairly sure it isn't
> part of GNU texinfo.

Whoops.  Not sure what I was thinking before, but kpsewhich is from my tetex
package too, and makeinfo, of course, from the texinfo package.  It seems to
be a separate GNU project (part of kpathsea), though maintained by the TeX
Users Group (TUG).  Here's some pages on it:,Introduction .

> Derek> Also, this still doesn't solve my problem.  My problem stems
> Derek> from the fact that 'texi2dvi' and 'texi2dvi --pdf' will use
> Derek> find two different texinfo.tex files and the two files don't
> Derek> appear to be compatibile - unless there is a texinfo.tex in the
> Derek> local directory ('.'), in which case both calls to 'texi2dvi'
> Derek> will use './texinfo.tex' and one call will produce garbage
> Derek> rather than readable output.
> Shouldn't `make dvi' do the right thing already here?

Ok, first the disclaimer.  I _do_ have my code doing the right thing, 'make
dvi', 'make info', 'make doc' (for postscript), & make 'pdf', but I used the
'no-texinfo.tex' automake option (to exclude texinfo.tex from the
distribution) and created the pdf & ps targets myself.

Anyhow, if I allow automake to include a texinfo.tex, yes, the dvi target
works fine, but the pdf target breaks.  This is because TeX normally uses
different paths dependent on which application called it and what the source
and destination file types are.  Kpsewhich accounts for this:

    address@hidden doc]$ kpsewhich texinfo.tex
    address@hidden doc]$ kpsewhich --progname=pdftex texinfo.tex

Unfortunately, '.' always comes first in TeX's paths, so files in the current
working directory ('.') take priority regardless of the application and the
source and destination file types:

    address@hidden doc]$ touch texinfo.tex
    address@hidden doc]$ kpsewhich texinfo.tex
    address@hidden doc]$ kpsewhich --progname=pdftex texinfo.tex

Unfortunately, at least with my installation of tetex, which I believe is
fairly current, the texinfo.tex used to generate pdf output and the
texinfo.tex used to generate all other types of output are not compatible.
Thus, when a texinfo.tex is included with my distribution, either the pdf
target is broken or all other doc targets are broken.  Neither case makes me
particularly happy.

I slogged my way through enough FAQs, documentation, and email archives to
lead me to believe that having the same *.texi file find two different
texinfo.tex files (say ./texinfo.tex & ./pdftexinfo.tex) depending on the
output isn't a common request.  I sent out a query to the pdftex mailing list
however.  I'll let you know if they inform me of an available workaround.

The best alternative hacks I came up with involve shuffling filenames around
with each build dependent on the target (e.g. renaming ./pdftexinfo.tex to
./texinfo.tex for a pdf build or retargeting a link), or putting each
texinfo.tex in a different subdir of 'doc' and playing with the TEXINPUTS
environment variable.  Neither solution seems aesthetically pleasing.


Derek Price                      CVS Solutions Architect ( )
mailto:address@hidden     OpenAvenue ( )
If at first you don't succeed, skydiving is not for you.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]