Introducing LaMake, a LaTeX build and deployment system

April 18, 2010

[Dear Planet KDE, sorry in advance for a totally non-KDE blog entry. I’ll stop blogging about this topic on Planet after this announcement.]

University courses have started again, so I have to stop hacking on Palapeli, and start hacking on uni-related stuff. At the lecture hall, we write all lecture notes in LaTeX (including formulas, diagrams, images etc.) and publish the documents on our website. At least theoretically.

In reality, we have not come around to updating any documents or publishing new ones over the whole last semester. There must be technical solution for this social problem! And there is one: fully automated nightly builds. As the only one here who owns a web server (which also hosts our internal Git repo), the task of setting up the build server was assigned to me.

Until now, my build system was a hacky script “”, wrapped by another equally-named hacky script in another directory. It was not very efficient, but got the job done for years. Anyhow, this solution is total cr… I mean, uh… very suboptimal for this new runtime environment.

The problem is that an automated LaTeX build system is a quite complicated task because of the (La)TeX system’s legacy. It’s not like a usual compiler which you run once over your file and get the desired output. Running LaTeX generates several temporary storage files, which need to be processed afterwards, and only then will another LaTeX run create the expected result by reading the changed temporary files. When I edit a LaTeX file, generating the PDF in general takes 3 LaTeX runs, but in distinct situations, one or two runs are sufficient. A good build system should recognize these situations.

Most existing LaTeX build systems have exotic dependencies (such as scons) which I do not want on my web server. Then there are Makefile-based LaTeX build systems such as latex-makefile. If you’re brave enough, take a look at this Makefile. This looks like a complete documentation of all of GNU make’s features, e.g. functions (I never knew such things were possible in Makefiles), so no chance one can safely add additional features without breaking everything (unless you’re a GNU make guru… I’m not).

So yet again, I considered it easier to write my own system, called LaMake. After two evenings of work, I am at the point where LaMake replaces my current build system with ease and a much better architecture, and even provides me with some new features such as “lamake clean”.

Much is left to do, though. As usual when you quickly need to replace a working system with new code, some parts are designed in a straight-forward manner. Also, the functionality is quite limited (e.g. no BiBTeX support because we do not use it here). Still, if you are interested in a Qt-based LaTeX build and deployment system, come join me at At the moment, documentation is limited to the “USAGE” file in the repository, but that should be enough to get you started in no time.


9 Responses to “Introducing LaMake, a LaTeX build and deployment system”

  1. Nico Says:

    You may wanna check out CTAN-hosted latexmk.

    • Stefan Majewsky Says:

      Looks nice, but after some nightmare experiences with the $TEXINPUTS environment variable, I have grown a general dislike against LaTeX build systems which try to be overly clever about finding dependencies.

  2. Miguel Says:

    Don’t know if you know it, but rubber is a pretty good build system for latex projects.

    • Stefan Majewsky Says:

      Besides the fact that Python falls into my personal “abstruse dependency” category, the same reasoning as in my reply to the very first comment applies. The structure of my source tree is quite complex, and I did not yet find a build system able to cope with this complexity.

      LaMake solves this problem because I specify dependencies manually. It might take 5 lines to type, but it does Just Work™ for me.

      • Arnar Says:

        Python comes standard now with almost all non-Windows operating system distributions. You call it an “abstruse dependency” but yet you have no problem building on QT. I don’t understand..

        • Stefan Majewsky Says:

          On a webserver, every added software needs maintenance. Maintenance means some minimum knowledge about the software in question. By introducing a Python dependency, I need to concern myself with monitoring its status and updating it, keeping myself up-to-date about possible security holes, etc.

          As I said, it’s my *personal* “abstruse dependency” category. Qt is not an abstruse dependency *for me* because I follow its development and get informed about security issues anyway.

  3. Markus Says:

    I don’t mind occasional non-KDE posts on Planet KDE esp. if they are about FOSS anyway.

  4. Ben Boeckel Says:

    I have done something similar to this with CMake. LaTeX and BibTeX support, out-of-source builds (no more cluttered directories!), support for gnuplot and other nice text-based tools, and other goodies that CMake brings. It was originally supposed to be a presentation about not using office software at all, but I’ve lost time to actually do that art.;a=summary

  5. Oystein S. Haaland Says:

    There is also:

    Which i have found to be very powerful and easy to use.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s