GNU bug report logs - #8099
LaTeX and automake

Previous Next

To reply to this bug, email your comments to 8099 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: bug-automake <bug-automake <at> gnu.org>
Subject: 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

Message #8 received at 8099 <at> debbugs.gnu.org (full text, mbox):

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 8099 <at> debbugs.gnu.org
Subject: Re: bug#8099: LaTeX and automake
Date: Sun, 27 Feb 2011 07:53:49 +0100

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

Message #11 received at 8099 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
Cc: 8099 <at> debbugs.gnu.org
Subject: Re: bug#8099: LaTeX and automake
Date: Sun, 27 Feb 2011 13:39:31 +0000

On 27 February 2011 06:53, Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> wrote:
> Anyway, the next step to pursue this would be to think hard about the
> desired semantics,

The tricky part here is that latexmk does its own dependency finding.
Hence, in my example rules I only list the root file for each
document.

I suppose that what one would want is something like the makedepends
support one gets from a C compiler, so that the dependencies could be
extracted by automake and included in the makefile automatically?

-- 
http://rrt.sc3d.org

Message #14 received at 8099 <at> debbugs.gnu.org (full text, mbox):

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 8099 <at> debbugs.gnu.org
Subject: Re: bug#8099: LaTeX and automake
Date: Sun, 27 Feb 2011 15:42:23 +0100

* Reuben Thomas wrote on Sun, Feb 27, 2011 at 02:39:31PM CET:
> On 27 February 2011 06:53, Ralf Wildenhues wrote:
> > Anyway, the next step to pursue this would be to think hard about the
> > desired semantics,
> 
> The tricky part here is that latexmk does its own dependency finding.

Well yes.  Also, as you already mentioned, latex semantics don't really
fit a directed graph where the nodes are files; rather, it needs a more
complex diagram of states of sets of files.  I don't think trying to map
that to portable make would be a worthwhile endeavor, given that latexmk
already exists.  I think we should just try to find rules that are safe
in the sense of: they call out to latexmk when needed, and not too often
when it is not needed.

> Hence, in my example rules I only list the root file for each
> document.

Right.  But that will fail to do TRT when you then go and edit another
file which becomes part of the document.

> I suppose that what one would want is something like the makedepends
> support one gets from a C compiler, so that the dependencies could be
> extracted by automake and included in the makefile automatically?

That could be an improvement.  Or, as a first step, just calling latexmk
every time.  Does it do anything if files are up to date?

Do you happen to know if latexmk works with pgfplots?

Thanks,
Ralf

Message #17 received at 8099 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
Cc: 8099 <at> debbugs.gnu.org
Subject: Re: bug#8099: LaTeX and automake
Date: Mon, 28 Feb 2011 00:39:13 +0000

On 27 February 2011 14:42, Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> wrote:
>
> Well yes.  Also, as you already mentioned, latex semantics don't really
> fit a directed graph where the nodes are files; rather, it needs a more
> complex diagram of states of sets of files.  I don't think trying to map
> that to portable make would be a worthwhile endeavor, given that latexmk
> already exists.  I think we should just try to find rules that are safe
> in the sense of: they call out to latexmk when needed, and not too often
> when it is not needed.

So I was thinking, latexmk could output a list of dependent files for
a given root file, and Make simply calls latexmk when any of them
changes.

> That could be an improvement.  Or, as a first step, just calling latexmk
> every time.  Does it do anything if files are up to date?

No, which is a good start!

> Do you happen to know if latexmk works with pgfplots?

It doesn't seem to know about it.

-- 
http://rrt.sc3d.org

Message #20 received at 8099 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
Cc: 8099 <at> debbugs.gnu.org
Subject: Re: bug#8099: LaTeX and automake
Date: Mon, 28 Feb 2011 14:24:57 +0000

Update: I've written to John to ask about copyright assignment, but
discovered in the mean time that there are one or two other authors to
talk to. I will see what John says first before considering how to
proceed.

I have also butchered the current version of latexmk to remove all the
functionality automake doesn't need (previewing, printing, and various
types of customisation, some other cruft).

This has reduced the LOC (counted with cloc, so actual code) from
3,724 to 2,916 lines.

The down side is that this is still long, and there seems to be a fair
amount of cruft. The upside is that this is very well commented code
(2,000 lines of comment for the remaining 3,000 lines of ocde). There
are a lot of notes about bits of doubtful code that should also
ideally be checked and sorted out.

If it sounds like an advantage to have a butchered version even
without a copyright assignment (i.e. a fork which is designed for
integration with make rather than interactive use), then I'd be happy
to publish it. If not, then I'll wait until I work out the story on
copyright assignment, but keep using my butchered version in the mean
time.

-- 
http://rrt.sc3d.org

Message #23 received at 8099 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
Cc: 8099 <at> debbugs.gnu.org
Subject: Re: bug#8099: LaTeX and automake
Date: Mon, 28 Feb 2011 14:39:13 +0000

By the way, before getting all excited about programming, maybe I
could just write some additional documentation for automake
recommending the use of latexmk and giving an example Makefile.am
fragment?

Message #26 received at 8099 <at> debbugs.gnu.org (full text, mbox):

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 8099 <at> debbugs.gnu.org
Subject: Re: bug#8099: LaTeX and automake
Date: Mon, 28 Feb 2011 21:43:33 +0100

Hi Reuben,

* Reuben Thomas wrote on Mon, Feb 28, 2011 at 03:24:57PM CET:
> Update: I've written to John to ask about copyright assignment, but
> discovered in the mean time that there are one or two other authors to
> talk to. I will see what John says first before considering how to
> proceed.

I'm not sure if I said it before; but I wouldn't be surprised if there
is interest to let latexmk (continue to) exist independently from
Automake.  Not all users of the former are likely to be using the latter
also.  It's not even clear how big the benefit of a merge would be; at
least to me it is not yet.

* Reuben Thomas wrote on Mon, Feb 28, 2011 at 03:39:13PM CET:
> By the way, before getting all excited about programming, maybe I
> could just write some additional documentation for automake
> recommending the use of latexmk and giving an example Makefile.am
> fragment?

Not just that.  You (or we) should be thinking hard about desired
semantics first.  And a small part of that is showing how example
rules would look like: both what you'd use now, without automake,
and also what you'd like to be using with automake support, and
also what automake would then generate for you.  Installation and
distribution semantics are next.  The code that comes from this can
then be written as new tests, and the rest as documentation patch.

Thanks,
Ralf

Message #29 received at 8099 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
Cc: 8099 <at> debbugs.gnu.org
Subject: Re: bug#8099: LaTeX and automake
Date: Mon, 28 Feb 2011 21:07:17 +0000

On 28 February 2011 20:43, Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> wrote:
> Hi Reuben,
>
>
> I'm not sure if I said it before; but I wouldn't be surprised if there
> is interest to let latexmk (continue to) exist independently from
> Automake.

That's what I was assuming.

>  It's not even clear how big the benefit of a merge would be; at
> least to me it is not yet.

It's more that I suspect given how big and crufty it is, automake
would want its own version that we could make smaller and less crufty,
including getting rid of functionality that is irrelevant to automake,
as I already discussed.

> Not just that.  You (or we) should be thinking hard about desired
> semantics first.  And a small part of that is showing how example
> rules would look like: both what you'd use now, without automake,
> and also what you'd like to be using with automake support, and
> also what automake would then generate for you.

I already exhibited examples of what I use now and what I would like
to see. To progress really needs more use cases.

-- 
http://rrt.sc3d.org

Message #32 received at 8099 <at> debbugs.gnu.org (full text, mbox):

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 8099 <at> debbugs.gnu.org
Subject: Re: bug#8099: LaTeX and automake
Date: Wed, 2 Mar 2011 23:12:03 +0100

I just learned about rubber which also aims to deal with latex documents.
Have you looked at it yet?

Thanks,
Ralf

Message #35 received at 8099 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
Cc: 8099 <at> debbugs.gnu.org
Subject: Re: bug#8099: LaTeX and automake
Date: Wed, 2 Mar 2011 22:13:28 +0000

On 2 March 2011 22:12, Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> wrote:
> I just learned about rubber which also aims to deal with latex documents.
> Have you looked at it yet?

No, I will do so.

-- 
http://rrt.sc3d.org

Message #38 received at 8099 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
Cc: 8099 <at> debbugs.gnu.org
Subject: Re: bug#8099: LaTeX and automake
Date: Thu, 3 Mar 2011 15:42:33 +0000

On 2 March 2011 22:13, Reuben Thomas <rrt <at> sc3d.org> wrote:
> On 2 March 2011 22:12, Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> wrote:
>> I just learned about rubber which also aims to deal with latex documents.
>> Have you looked at it yet?
>
> No, I will do so.

Initial impressions are good: rubber is much more cleanly written than
latexmk, and I can use pretty much the same automake rules with it:

LATEX_SRCS = ... # top-level .tex files

LATEX_PDFS = ... # top-level PDF outputs

pdf-local: $(LATEX_PDFS)

CLEANFILES = $(LATEX_PDFS)

clean-local:
	$(RUBBER) --clean $(PAPER_SRCS)

EXTRA_DIST = $(LATEX_SRCS)

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

I distribute the PDFs, so change CLEANFILES to MAINTIANERCLEANFILES.

I have not tried extracting dependency information yet, but it seems
very straightforward: rubber-info --deps foo.tex gives a
space-separated list of all the dependencies. So, other than worrying
about filenames containing spaces (sigh), one would imagine just
adding that information to the Makefile.

This means, effectively, delegating the semantics of rebuilding to
rubber, but that seems a reasonable starting-point.

Thoughts?

-- 
http://rrt.sc3d.org

Message #41 received at 8099 <at> debbugs.gnu.org (full text, mbox):

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 8099 <at> debbugs.gnu.org
Subject: Re: bug#8099: LaTeX and automake
Date: Fri, 4 Mar 2011 18:14:26 +0100

* Reuben Thomas wrote on Thu, Mar 03, 2011 at 04:42:33PM CET:
> 
> Thoughts?

We could just provide thin-layer support for both latexmk and/or rubber.

That would probably be the least amount of work, both inside Automake,
and for getting any missing bits into the upstream projects.

Thanks,
Ralf

Message #44 received at 8099 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
Cc: 8099 <at> debbugs.gnu.org
Subject: Re: bug#8099: LaTeX and automake
Date: Fri, 4 Mar 2011 20:45:18 +0000

On 4 March 2011 17:14, Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> wrote:
> * Reuben Thomas wrote on Thu, Mar 03, 2011 at 04:42:33PM CET:
>>
>> Thoughts?
>
> We could just provide thin-layer support for both latexmk and/or rubber.

This sounds good, and John Collins has pointed out that latexmk does
provide dependency information (not quite what we want yet, but he's
willing to help fix it), and supplied some useful comparison with
Rubber, suggesting that latexmk is better at ferreting out
dependencies.

> That would probably be the least amount of work, both inside Automake,
> and for getting any missing bits into the upstream projects.

Agreed.

It seems that we're up to deciding what shape the automake interface
should take, given that we expect a tool that supports, in the
abstract:

$(LATEX_MAKER) [--deps|--make|--clean] root.tex

-- 
http://rrt.sc3d.org

Message #49 received at 8099 <at> debbugs.gnu.org (full text, mbox):

From: Luke Dalessandro <ldalessandro <at> gmail.com>
To: 8099 <at> debbugs.gnu.org
Subject: Re: bug#8099: LaTeX and automake
Date: Mon, 6 May 2013 15:14:06 -0400

Are there any updates on integrating either latexmk or rubber-based builds as standard infrastructure in automake?

Luke

Message #52 received at 8099 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Luke Dalessandro <ldalessandro <at> gmail.com>
Cc: 8099 <at> debbugs.gnu.org
Subject: Re: bug#8099: LaTeX and automake
Date: Tue, 07 May 2013 00:08:59 +0200

On 05/06/2013 09:14 PM, Luke Dalessandro wrote:
> Are there any updates on integrating either latexmk or
> rubber-based builds as standard infrastructure in automake?
> 
> Luke
> 
Attempting to write patches myself about this is not on my radar
ATM, so I fear we are stuck at "patches welcome".  Sorry.

Regards,
  Stefano

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.