11

imakeidx and latexmk are two of my favorite utilities of all TeX-time, especially in the face of book-size compilations (super thanks @egreg and @John Collins!). Apart from ease of producing multiple indices, one of the most useful properties of imakeidx is in-document compilation index sub-compilation (how I wish glossaries and biblatex could be extended to behave the same way!)

Given MWE:

\documentclass{article}
\usepackage{imakeidx}
\makeindex

\begin{document}

This.\index{this}

\printindex

\end{document}

makeindex is invoked once midway during straightforward latex compilation. However, when using latexmk -recorder (etc.), latexmk ignores the new .ind file that imakeidx produces half-way through and invokes makeindex on the .idx file all over again.

Of course, this inefficiency is hardly noticeable with this toy MWE. But given many-filed book-size documents with multiple large indices, biblatex/biber, multiple glossaries and several tocs necessitating several passes before reaching completion, the extra work that latexmk creates (rather than eliminates) tests my sense of elegance (and sometimes my patience) greatly.

How, then, can I improve latexmk's over-eagerness to invoke makeindex in documents using imakeidx? I'm hoping for some simple rules to add to my .latexmkrc. I am particularly interested in keeping the number of makeindex invocations to a minimum across multiple passes (not shown with this MWE) -- say, to a maximum of two invocations per any index file.

[[ Bonus points for extending glossaries and/or biblatex capability for in-document compilation a la imakeidx's brand of \write18 magic. ; ) ]]

Improve this question
4
  • 2
    Arara is a candidate worth trying for jobs like this. It is easily configureable.
    – user11232
    Aug 23, 2012 at 14:50
  • 1
    @Harish — thanks for that. Arara certainly looks like a useful tool (kudos also for its tremendously readable manual. I wish many others could be so good — biblatex manual authors are you listening!??). Still, I'm struggling to see how it might fit the bill without make-like dependency-conditioned compilation. To me, it seems ideal for configuring "straight through" processing, but, without diving into Java coded rules, it doesn't solve my problem – efficient dependency-constrained assembly pipeline automation. However, please correct me if it is up to this and I'll take another look.
    – Nikki
    Aug 24, 2012 at 3:54
  • 1
    The added advantage of arara is the author and his friends (@Paulo Cereda, @Marcodaniel and Brent) are very generous and helpful. You can get good help here.
    – user11232
    Aug 24, 2012 at 5:56
  • @Harish, yes, very true. Plus they know how to write a really great user manual. Trouble is, for all its other graces, arara just can't solve the problem asked above. BTW, in fairness, latexmk's author John Collins is equally active, generous etc. in this and other fora. : )
    – Nikki
    Aug 24, 2012 at 14:47

2 Answers 2

Reset to default
11

I don't see any way of configuring the current version of latexmk to prevent it doing the extra runs. Not only is makeindex run a second time by latexmk, but so is latex, so the run time is doubled, which is a bad penalty on a large document.

To correct this needs changes in latexmk itself. There is enough information in the .log file for latexmk to determine that the .ind file was made during the run of latex before it was read, and therefore to show that the extra runs are not needed. I've added this to my list of enhancements for a future version of latexmk.

Improve this answer
1
  • I guess my question was that supposing I use imakeidx for all index (.idx, .ind) file production, would there be any way of preventing latexmk from invoking the makeindex program by configuring a rule for this in my local .latexmkrc? I.e., instruct latexmk to completely ignore .idx -> .ind production. I've tried to achieve this by configuring/removing local dependencies rules, but haven't got very far.
    – Nikki
    Aug 24, 2012 at 8:32
5

Not to take away anything from John's answer, adding $makeindex = "touch -m %D"; to the local .latexmkrc produces automated workflow with nearly minimal overhead. In which case, on my system with this example, latex is only run once. I.e., this is (nearly) as efficient as things can ever get. The proviso, of course, is that imakeidx with \write18 enabled is always used — not a problem in my case.

(*) Windows users can pick up a copy of touch.exe in any modern gnu distribution.

Improve this answer
2
  • 1
    That's the case on the first run of latexmk. But if you change the file by something that affects the index (e.g., by adding \index{that}), and you then rerun latexmk, you will find it does a second run of latex. The problem is that the .ind file changed between the start and end of the first run of latex; that is an indication that the output file is out-of-date.
    – John Collins
    Aug 24, 2012 at 16:45
  • 1
    @John, very true. However, of little impact with non-trivial documents, i.e., most real-world docs needing multiple compiles (where second runs will be happening anyway). Given latexmk's $makeindex command redefined above, the burden of a second touch is negligible, and much less than extra invocations of makeindex (esp. in multi-indiced docs). Certainly not ideal, of course, and much uglier than were latexmk to acquire a -makeindex- command line switch a la the most useful -bibtex- option and/or some more programmatic way to turn off makeindex dependencies processing.
    – Nikki
    Aug 25, 2012 at 8:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.