reitzig / ltx2any

Yet another LaTeX build wrapper, with one or two nifty features
GNU General Public License v3.0
59 stars 4 forks source link

Only compile if necessary #63

Closed koppor closed 8 years ago

koppor commented 8 years ago

I am a user of latexmk and have that mindset.

When nothing in the source files changed, there should also be no compilation. Possibly the statement "Automatically compiles as often as necessary" from the README should be explained. When reading the help, I read -n How often the LaTeX engine runs.. Why is such a parameter necessary if ltx2any "compiles as often as necessary"?

akerbos commented 8 years ago

I have not used latexmk, but I daresay that any such heuristic can be simplistic at best. The approach I've been taking is: if anything changes in this directory, rebuild. It's the users' responsibility to have a "clean" directory.

The reason for this is that the LaTeX "parser" can be rewritten at runtime so it is, in general, impossible to know which changes to files affect the document.

If -d seems to trigger rebuilds without reason you may have found a bug.


-n is necessary for when the heuristic fails. In particular, there are cases when the PDF never converges; then you need -n to make the process stop at all. Furthermore, if you know one or two runs are sufficient you can use -n and save the last run, which is only needed to detect that nothing has changed anymore.

In principle, it is also possible to design commands that do not change their output for a couple of runs but then do. The heuristic would be fooled by that and would need to be overridden. I don't know of an example of this, though.

koppor commented 8 years ago

I am not talking about continuous compilation. I'm just talking about running ltx2any once. I expect that ltx2any compiles until nothing changes. However, it tries to keep the compile count as low as possible. For instance, if there is no biber run necessary, biber should not be run. Reading your comment, I'm not sure whether that is implemented.

Maybe this is broken on Windows? Here my consecutive calls:

> ruby c:\git-repositories\ltx2any\ltx2any.rb -lf pdf minimal-only-document.tex
[ltx2any] Initialising ... Done
[ltx2any] Copying files to tmp ... Done
[ltx2any] PdfLaTeX(1) running ... Done
[ltx2any] PdfLaTeX(2) running ... Done
[ltx2any] There were 0 errors and 0 warnings.
[ltx2any] Output generated at minimal-only-document.pdf
[ltx2any] Assembling log files ... Done
[ltx2any] Log file generated at minimal-only-document.log.pdf

> ruby c:\git-repositories\ltx2any\ltx2any.rb -lf pdf minimal-only-document.tex
[ltx2any] Initialising ... Done
[ltx2any] Copying files to tmp ... Done
[ltx2any] PdfLaTeX(1) running ... Done
[ltx2any] PdfLaTeX(2) running ... Done
[ltx2any] There were 0 errors and 0 warnings.
[ltx2any] Output generated at minimal-only-document.pdf
[ltx2any] Assembling log files ... Done
[ltx2any] Log file generated at minimal-only-document.log.pdf

The first run should only run once as a second run is not necessary.

The second run should output "nothing chanced, no compilations necessary" instead of calling pdflatex twice.

File used:

\documentclass{article}
\usepackage{blindtext}
\begin{document}
\blindtext
\end{document}
akerbos commented 8 years ago

Ah, I see what you mean now.

Information about generated files is not kept between separate calls. The assumption is that you won't rerun unless things changed. Thus, ltx2any will always need at least two runs unless you specify -n 1. Do you have a compelling reason for changing this?

By the way, there is no advantage in calling ltx2any independently. One call with -d is always superior, afaik.
That is, if there are no bugs and the listen gem does not create high load on Windows. So, if there is a reason you don't want to use -d, I'm all ears.


Rationale for the feature: you need one run more than necessary to verify convergence, but then you know it was enough (exotic, theoretical cases aside). Also, in -d mode the first iteration may need four runs of the engine plus extensions, but subsequent ones only one. With -n 4 you'll have four runs ever iteration, with the heuristic you'll have 5 + 2 + 2... -- this pays off quickly.

koppor commented 8 years ago

Main reason

[ltx2any] Took 0 min 53 sec

Sometimes, I want to see how the result looks like or check whether I have syntax errors. OK, maybe I should just get used that I cannot wait for a compilation run to finish and should continue working on something else. But that's an context switch :disappointed:.

My current solution is to use latexmk for the daily writing job (also has a -d equivalent -pvc if desired, but not used here) and ltx2any for the final checking: the error messages are output more nicely. The alternative is to execute pdflatex in case a quick build is needed and ltx2any if a new bibliography entry came in.

akerbos commented 8 years ago

I hear you. Compiling big LaTeX documents is a pain, time-wise.

Some hints:

  1. Use draft mode (document class option).
  2. Identify packages that take the most time and try to find solutions. For example, use TikZ externalization (but disable it for todonotes if you use those); disable minted in draft mode; and so on.
  3. Translate only the chapter you're working on; cf. \includeonly.
  4. Use -n 1 option of ltx2any. Not everything may be right, but for a quick, localized check it may be enough. If paired with -d, everything will be right eventually. Save often.

My personal strategy is to have ltx2any -d running and hit save often. By the time I finish the paragraph or so, the first part will already have shown up in the viewer.

Some of your problems may be partly solved by using an IDE. The only one I found bearable is TeXlipse, but YMMV.

That said, even our 300p exercise problem/solution pool compiles in <20s on a regular office laptop. TikZ externalization is certainly a big timesaver, and we don't use many other time-heavy packages. So suspect that you do something "nifty" which you may be able to rationalize away for most compilation runs.

the error messages are output more nicely

I'm glad, that was one of my main goals. :)

The alternative is to execute pdflatex in case a quick build is needed

ltx2any -n 1 does little more than that, and you'll get the nice log.

akerbos commented 8 years ago

FWIW: #67