Re: [Fwd: --add-missing]
Tom Tromey wrote: > I wouldn't be averse to adding a `pdf' target so that `make pdf' works > as expected. Someone else would have to write it though since I don't > know how. It should be the exact target used for DVI except for the addition of a '--pdf' switch to the texi2dvi command line. I'm using the following, stripped directly from my Automake generated Makefile.in's DVI targets, but I didn't research enough to know if any of the constituent elements (TEXINPUTS, MAKEINFO, makeinfo includes) vary with Makefile.am parameters: SUFFIXES = .aux .txt .pdf # texinfo based targets automake neglects to include .texinfo.pdf: TEXINPUTS=$(srcdir):$$TEXINPUTS \ MAKEINFO='$(MAKEINFO) -I $(srcdir)' $(TEXI2DVI) --pdf $< .txi.pdf: TEXINPUTS=$(srcdir):$$TEXINPUTS \ MAKEINFO='$(MAKEINFO) -I $(srcdir)' $(TEXI2DVI) --pdf $< .texi.pdf: TEXINPUTS=$(srcdir):$$TEXINPUTS \ MAKEINFO='$(MAKEINFO) -I $(srcdir)' $(TEXI2DVI) --pdf $< By the way, there may not be much demand for it any longer, but we have legacy targets to generate ASCII versions of our manuals as well. I'm told they ocassionally came in handy for mailing: .texinfo.txt: TEXINPUTS=$(srcdir):$$TEXINPUTS \ MAKEINFO='$(MAKEINFO) -I $(srcdir)' $(MAKEINFO) $< --no-headers -o $@ .txi.txt: TEXINPUTS=$(srcdir):$$TEXINPUTS \ MAKEINFO='$(MAKEINFO) -I $(srcdir)' $(MAKEINFO) $< --no-headers -o $@ .texi.txt: TEXINPUTS=$(srcdir):$$TEXINPUTS \ MAKEINFO='$(MAKEINFO) -I $(srcdir)' $(MAKEINFO) $< --no-headers -o $@ Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- This is the fourth? - Thomas Jefferson's last words (he died on the 4th of July)
Re: [Fwd: --add-missing]
Derek> I slogged my way through enough FAQs, documentation, and email Derek> archives to lead me to believe that having the same *.texi file Derek> find two different texinfo.tex files (say ./texinfo.tex & Derek> ./pdftexinfo.tex) depending on the output isn't a common Derek> request. I sent out a query to the pdftex mailing list Derek> however. I'll let you know if they inform me of an available Derek> workaround. Ok, now I'm lead to believe that the latest texinfo.tex can handle both ps and pdf generation. So hackery shouldn't be needed -- I'll just include the latest texinfo.tex in the next automake release like I always do. I wouldn't be averse to adding a `pdf' target so that `make pdf' works as expected. Someone else would have to write it though since I don't know how. Tom
Re: [Fwd: --add-missing]
Tom Tromey wrote:
> > "Derek" == Derek R Price <[EMAIL PROTECTED]> 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 standards.info 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
difference.
> 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:
http://www.cis.ohio-state.edu/cgi-bin/htbin/info/info/kpathsea,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:
[dprice@empress doc]$ kpsewhich texinfo.tex
/usr/share/texmf/tex/texinfo/texinfo.tex
[dprice@empress doc]$ kpsewhich --progname=pdftex texinfo.tex
/usr/share/texmf/pdftex/texinfo/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:
[dprice@empress doc]$ touch texinfo.tex
[dprice@empress doc]$ kpsewhich texinfo.tex
./texinfo.tex
[dprice@empress doc]$ kpsewhich --progname=pdftex texinfo.tex
./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
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
If at first you don't succeed, skydiving is not for you.
Re: [Fwd: --add-missing]
> "Derek" == Derek R Price <[EMAIL PROTECTED]> 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 standards.info appears in /usr/info/.
>> 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.
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.
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?
Tom
Re: [Fwd: --add-missing]
Tom Tromey wrote:
> > "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
>
> Derek> Yep. Looks like that could be used by configure to set, say,
> Derek> TEX_TEXINPUTS & PDFTEX_TEXINPUTS and prepend include dirs
> Derek> differently for different targets, but I suspect that if your
> Derek> TeX distribution includes kpsewhich then your TeX applications
> Derek> can already find the appropriate texinfo.tex.
>
> Me too. But the point is that GNU packages are supposed to ship with
> texinfo.tex.
Is there a web page somewhere with this standard on it? I browsed
briefly but I haven't been able to locate one.
> I'm reluctant to rely on kpsewhich. What if we changed makeinfo to
> have an option to print the path to texinfo.tex? Then automake could
> run this program instead of installing its own private copy of
> texinfo.tex.
>
> This would guarantee that the maintainer gets the texinfo.tex that
> matches his makeinfo.
What's the difference? Who maintains makeinfo? The makeinfo on my
system seems to have been installed with my texinfo package anyhow, the
same place kpsewhich came from.
Also, this still doesn't solve my problem. My problem stems from the
fact that 'texi2dvi' and 'texi2dvi --pdf' will use find two different
texinfo.tex files and the two files don't appear to be compatibile -
unless there is a texinfo.tex in the local directory ('.'), in which
case both calls to 'texi2dvi' will use './texinfo.tex' and one call will
produce garbage rather than readable output. Any fix that would get by
my system would have to either include both 'texinfo.tex' files and do
some fancy include munging depending on the target or notice that a tex
package containing 'texinfo.tex' was already installed and not create
the version in the local directory. Configure could probably handle
this second solution - perhaps if 'kpsewhich' exists and returns a
default 'texinfo.tex' then it leaves 'texinfo.tex.in' alone. Otherwise
it copies it into 'texinfo.tex'.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
I find that the harder I work, the more luck I seem to have.
- Thomas Jefferson
Re: [Fwd: --add-missing]
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes: Derek> Yep. Looks like that could be used by configure to set, say, Derek> TEX_TEXINPUTS & PDFTEX_TEXINPUTS and prepend include dirs Derek> differently for different targets, but I suspect that if your Derek> TeX distribution includes kpsewhich then your TeX applications Derek> can already find the appropriate texinfo.tex. Me too. But the point is that GNU packages are supposed to ship with texinfo.tex. I'm reluctant to rely on kpsewhich. What if we changed makeinfo to have an option to print the path to texinfo.tex? Then automake could run this program instead of installing its own private copy of texinfo.tex. This would guarantee that the maintainer gets the texinfo.tex that matches his makeinfo. Tom
[Fwd: --add-missing]
Yep. Looks like that could be used by configure to set, say, TEX_TEXINPUTS & PDFTEX_TEXINPUTS and prepend include dirs differently for different targets, but I suspect that if your TeX distribution includes kpsewhich then your TeX applications can already find the appropriate texinfo.tex. Of course, I suppose this could still be used to find a more recent texinfo.tex than was included with your automake distribution, which would work slightly better than including an out-of-date texinfo.tex, but the included texinfo.tex will still render PDF targets unbuildable since texi2dvi will, by default, prefer a texinfo.tex in '.' over one elsewhere. In other words, a complete solution is probably some combination of these two, so that TEX_TEXINPUTS or PDFTEX_TEXINPUTS is used when available and the included texinfo.tex is used when the appropriate texinfo.tex can't be found. This is a little more work, but it seems much less baroque than mv'ing texinfo.tex out of the way when a better one is found. Then again, maybe you can find a way to make that work. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- ... one of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs. - Robert Firth Hi, "Derek R. Price" <[EMAIL PROTECTED]> writes: > Alexandre Oliva wrote: > > On Nov 13, 2000, "Derek R. Price" <[EMAIL PROTECTED]> wrote: > > > Okay, is there some way short of symlinking the > > > /usr/share/automake/texinfo.tex file by hand to make sure that automake > > > --add-missing uses the "proper" texinfo.tex file (i.e. the one installed > > > with the texinfo package and assumedly the most recent one)? > > > > I'm afraid not. Any suggestions about how automake could find out > > where texinfo.tex from the texinfo package is installed, assuming it > > is? > > Well, after sifting the documentation for my distribution for several hours, > I have discovered the "texmf.cnf" file. It appears to define all sorts of > possible search paths dependant on the format of your input and output files. Assuming you're using teTeX (likely for most recent UNIX TeX installations), you look for things using the 'kpsewhich' program, like in kpsewhich texinfo.tex The texmf.cnf file should be treated as an internal detail. - Hari -- Raja R Harinath -- [EMAIL PROTECTED] "When all else fails, read the instructions." -- Cahn's Axiom "Our policy is, when in doubt, do the right thing." -- Roy L Ash
