Until recently I always compiled my documents via the steps, pdflatex -> makeindex/biber -> pdflatex -> pdflatex (and the intermediate steps only if necessary).

Latexmk does all the necessary steps in one command for me but I suspect that comes with a drawback, what is it? One I can think of is that it maybe runs unnecessary steps and so it is a bit slower or is that not even true? Are there drawbacks for using latexmk?

  • 3
    I don't think there are any drawbacks from using latexmk. What you have to do is configure it before use. You can either do that using a global latexmkrc or a local one in your project's folder. If you think that latexmkmight run unnecessary comilation, then you might want to have a look at arara, which gives you full control over all steps done. Its successor nightingale will even support conditional execution of those steps. Jun 4, 2015 at 7:51
  • 3
    i can think of only one drawback, and it's rather specialized. sometimes it's necessary to look at or save an "interim" version of a .toc or .aux file, and latexmk would automatically wipe those out. so the only way to avoid that is to perform the process step by step. Jun 4, 2015 at 12:54
  • Thanks for the comments. That's something I can live with :)
    – Philipp
    Jun 8, 2015 at 15:31

1 Answer 1


(As the author of latexmk, I am naturally partial to my own program, but here's my 2-cents' worth anyway.)

The fundamental problem that latexmk solves is that the number of runs of (pdf)latex needed is highly dynamically dependent on the document and the class file used. If you make a small change to a document, often only one recompilation by (pdf)latex is needed, but not always. But some cases consistently need at least 4 runs. So running a fixed sequence of programs is definitely non-optimal. Latexmk is designed to perform the right number of runs of the programs involved as reliably as possible while only using a small amount of resources compared with the called programs; most of the running time goes to (pdf)latex under normal situations.

The method it uses is to determine the set of all input files and to efficiently test for changes in content since the last run. If the content of an input file has changed, a new compilation is made. For normal documents, this process works correctly.

One other advantage of latexmk is that if your document includes graphics files that need to be converted from the native form for the graphics editor (e.g., xfig), then latexmk can be configured do an automatic conversion to the format needed for (pdf)latex, e.g., .pdf or .eps. For a human, it's one more mechanical step that's easy to forget occasionally, especially in documents with tens or hundreds of graphical elements.

The only regular case I know where latexmk consistently does an extra run, is that in the case mentioned by the OP, latexmk does an extra run of bibtex between the second and third runs of pdflatex. It does this because the .aux file changed after the second run of pdflatex, and latexmk does not know that the particular changes that occurred do not actually matter to bibtex's output. The extra time for the bibtex run is small enough that it hasn't seemed worthwhile to do extra testing to optimize it.

As for when latexmk fails do enough runs, the cases I know of are when compilation of a document runs external programs or luatex code to process external files. In these cases, latexmk doesn't normally know about the external files because the file names aren't reported by the running compilation, although that can be fixed. However, for most people creating LaTeX documents this situation doesn't occur.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .