latexmk / imakeidx interoperational efficiency

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. ; ) ]]

-
Arara is a candidate worth trying for jobs like this. It is easily configureable. –  Harish Kumar Aug 23 '12 at 14:50
@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 '12 at 3:54
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. –  Harish Kumar Aug 24 '12 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 '12 at 14:47

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.
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 '12 at 8:32
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. - 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 '12 at 16:45 @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 '12 at 8:14