bug-automake
[Top][All Lists]
Advanced

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

bug#8099: LaTeX and automake


From: Reuben Thomas
Subject: bug#8099: LaTeX and automake
Date: Tue, 22 Feb 2011 21:43:51 +0000

I have just been investigating the state of the art for LaTeX support.
As far as I can tell there's nothing official; the most "official"
things I can find are some unwritten documentation in the autotoolset
manual:

http://autotoolset.sourceforge.net/tutorial.html

and this project suggestion by Akim Demaille with the apparent
knowledge of Alexandre Duret-Lutz:

http://www.lrde.epita.fr/cgi-bin/twiki/view/Epita/ProjetsLibres#Automake_LaTeX_Support_and_tests

which given their involvement in auto* suggests nothing has been done
(although the page I quote is a few years out of date).

I've just been autotooling up an old build system of mine from 15
years ago, and needed to build several LaTeX documents of modest
complexity, and had no desire to fake up the relevant Make rules.

I looked into several LaTeX builder scripts.

I first tried LaTeX-mk, which is a Perl script optionally augmented by
some Makefile fragments. I ignored the Makefile fragments as they need
either GNU Make or "a BSD make program". LaTeX-mk itself, which I've
used successfully for some time to build PDFs on the fly for my
personal web site, sadly seems to break down in parallel builds.

LaTeX-make looks better, as it uses what is says is a generic
Makefile, but integrating that would've required writing support for
automake. (The fact of being written in Make is not really an
advantage.)

I have used earlier versions of Wybo Dekker's "mk", but the current
version is written in Ruby, which is a bit of an annoying dependency.

Finally, I found latexmk (which took some disambiguating) by John Collins:

http://www.phys.psu.edu/~collins/software/latexmk-jcc/

This is a single Perl script, so I can at least require it in
maintainer mode. Since this seems to be good practice for LaTeX
documents anyway, since otherwise users must have a full LaTeX system
installed, and LaTeX can be quite fiddly, I thought it a reasonable
compromise to distribute PDF files as EXTRA_DIST. It worked in
parallel and VPATH builds (i.e. make distcheck with MAKEFLAGS
containing "-j 2" was no problem), and I ended up with the following
rules:

PAPER_SRCS = \
        $(srcdir)/foo.tex \
        $(srcdir)/bar.tex \
        ...

PAPER_PDFS = \
        $(builddir)/foo.pdf \
        $(builddir)/bar.pdf \
        ...

pdf-local: $(PAPER_PDFS)

mostlyclean-local:
        $(LATEXMK) -c $(PAPER_SRCS)

# This would be clean-local, but we distribute the PDFs
maintainer-clean-local:
        $(LATEXMK) -C $(PAPER_SRCS)

EXTRA_DIST = $(PAPER_SRCS) $(PAPER_PDFS)

.tex.pdf:
        $(LATEXMK) -pdf $<

I'd be interested to know if this is of any interest for automake.
(latexmk is distributed under the GPL, and has a single author, so
there's a chance of a copyright assignment, should that be important,
though I haven't asked the author about it.) To really support it
properly in automake, some work would obviously be needed to add for
example a LATEXS primary, with suitable prefix for installation under
${datadir}/doc, and some version of all the rules above, presumably
with the different default that the PDF files are not distributed, as
for texinfo, so that I could write simply:

doc_LATEXS = foo.tex bar.tex

EXTRA_DIST = foo.pdf bar.pdf

And I guess there would be a certain amount of pain making the `pdf'
target work for LaTeX and texinfo; are there other cases in which
suffixes are shared between different toolchains?

-- 
http://rrt.sc3d.org





reply via email to

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