bug#8099: LaTeX and automake

[Ralf Wildenhues]

Hello Reuben,

* Reuben Thomas wrote on Tue, Feb 22, 2011 at 10:43:51PM CET:
> I have just been investigating the state of the art for LaTeX support.

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

I agree with your reasoning pro latexmk.  LaTeX-mk seems to have too few
features to be generally useful, and I didn't bother to install
LaTeX-make because it would have triggered updating/replacing of roughly
70 packages on my currently half-stable half-oldstable Debian.

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

That looks fairly straightforward.  Almost too easy to warrant special
support.  ;-)

> I'd be interested to know if this is of any interest for automake.

Well, I'm not sure if you're aiming for integrating latexmk fully in
Automake (which I'm guessing the original author might not desire),
or just having automake produce something like the above rules for you.
The latter might be doable.  It is not clear how to arrive at a
sufficiently precise list of prerequisites.

> doc_LATEXS = foo.tex bar.tex
> 
> EXTRA_DIST = foo.pdf bar.pdf

That strikes me as suboptimal.  I have LaTeX sources that include lots
of other sources, .tex ones, but also images, graphs, all sorts of
generated stuff.  At the very least, you'll want to be able to specify
multiple sources.  The _TEXINFOS support for specifying additional
sources is a bit un-idiomatic, maybe we can have a spelling that
includes the _SOURCES name (but foo_tex_SOURCES is technically wrong
too)?  And extra dependencies of course.

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

Well, as long as can say for an individual target which it comes from it
should be doable.

Anyway, the next step to pursue this would be to think hard about the
desired semantics, and write them down precisely, ideally as patch
against the current documentation and accompanied with testsuite
additions.  ;-)

Hope that helps.

Thanks,
Ralf