Home

LaTeX Makefile

The LaTeX Makefile aims to be a single file that you can drop into a directory full of latex stuff, type "make" and watch the magic happen. It infers dependencies, builds many common graphic formats (and does translation between them) and ideally has minimal system dependencies.

To get started, you can try

make help | more

Another useful thing to try is

make _check_programs

That tells you whether you have the right things installed on your system to do what you need to do.

Known Issues

Some of these are easier to fix than others. These are the things that I could really use some help with, also, since my time is limited, although I remain committed to making this the most useful makefile for LaTeX out there.

Testing is inadequate

We need better, more reproducible test cases and a way to run them automatically. Right now the only real testing is for the various bits of sed script that go into making the makefile work properly. The way the tests work is this: I make a change, create all of the golden files, and manually inspect the changes using git's diff tool. This works for some changes, but not for others.

Additionally, there are not really any tests for actual document output. That really needs to happen.

Cleaning doesn't clean for pdflatex anymore

There was a change made to pdflatex in the last couple of years that causes files like "foo.eps" to be converted to "foo-eps-converted-to.pdf" files. This seems convenient in a lot of ways, but it is confusing the heck out of the makefile's automated cleaning mechanism.

Horrible repetition within the makefile

When the makefile was originally developed, the most common version of make in the wild was 3.79 and it had a serious bug with $$ macro expansion, which meant that I couldn't refactor things the way that I wanted to. That's why, if you've looked at the source, you will see multiple long lists of things like this:

all_files.tex      ?= $(wildcard *.tex)
all_files.tex.sh   ?= $(wildcard *.tex.sh)
all_files.tex.pl   ?= $(wildcard *.tex.pl)
...
<and on and on>

These could pretty easily be collapsed into just a couple of lines with the right make definitions. Now that 3.81 is the most common version out there, this could be fixed and made much clearer and more compact.

In the process of doing that compaction, I suspect that some bugs will be uncovered that were otherwise hidden in a large pile of repetitive code.

Subdirectories are just plain broken

I don't know of an easy way to fix this, because LaTeX makes strong assumptions about where things are, and so does make. The interplay between these makes it difficult to allow subdirectories, and fixing that has been my number one request over the years. I have seen numerous proposals, and it looks like some of them might even work. I am looking specifically for a proposal that makes it easy to continue tracking dependencies, knowing what was built, etc. Even if we have to strongly suggest that people do subdirectories in a specific way (e.g., using \graphicspath), that would be better than what we have now.

Also, it would be amazing if we could figure out how to put all generated files into a special build directory. This would make cleanup super easy, but it is a pretty foreign concept to LaTeX.

LaTeX-based graphic generation is impossible to do with full automation when using the pdf toolchain

This is a pdflatex-and-friends problem. The dvi->ps toolchain works fine because batch mode just skips graphics that it can't find and dumps errors in the logs. With pdflatex, there are certain classes of graphics that just cause it to stop, even in batch mode, and there is no real way of coercing it into continuing anyway.

It turns out that there is a whole class of images for which this happens, and some parts of that even have the problem in the dvi toolchain. For example, pstex has this problem, and there is really no way for LaTeX to continue when it can't find the relevant files: it has to include them in order to know what to process.

The solution for people using these kinds of things has previously been to have a special make target like "all-pstex" that builds those files first. I think we can do better with a little cleverness.

Sed+Sh+Grep is actually a horrible way to do this

Sed is actually really amazing and awesome. BSD sed, much less so, but that's what we have by default on Macs and other systems. So, the lowest common denominator wins.

I am absolutely open to using something else that is commonly already installed. I could use some help finding out what that language should be. Off the top of my head, here are a few things that I would be thrilled to consider using as the underlying technology:

• Python
• Perl
• Awk
• Lua

I would be interested to know what is commonly installed by default on platforms that people care about, like

• Cygwin
• Mac OS X, various versions
• Ubuntu, various versions
• etc.

I do most of my work on OS X, so I have something of a handle on that, but could still use information on earlier and later versions. I rarely have the latest, and I don't remember the earlier ones. I'm usually a major version behind.