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