[Omake] Rules execute in the wrong order

[Aleksey Nogin]

Luis,

The issue here is that in LaTeX rules, we also call "[pdf]latex 
-recorder" in _scanner_ rules to deduce dependencies. So it is 
insufficient to say "a.pdf: x.pdf", instead you need either:

- an explicit ".SCANNER: scan-pdflatex-a.tex: x.pdf" dependency, or

- an implicit ".SCANNER: scan-pdflatex%: x.pdf" dependency, or

- just designate x.pdf as a "generated TeX source file" that needs to be 
present before any scanning is done:

TeXGeneratedFiles(x.pdf)

(http://omake.metaprl.org/omake-build.html#fun:TeXGeneratedFiles has 
slightly more).

P.S. The execution order for "unrelated" rules in OMake is intentionally 
nondeterministic - this makes it easier to find missing dependencies. I 
would also recommend having "-j2" (or greater for SMP machines - 2x 
number of procs is usually a reasonable number) in the OMAKEFLAGS 
environment variable. This should make the compilation faster and 
dependency omissions more obvious.

On 13.03.2007 20:16, Luis O'Shea wrote:

> I have run into a problem with rules executing (seemingly) in the
> wrong order.  To make matters worse, the problem does not seem to be
> deterministic -- sometimes everything just works.
> 
> I have
> 
> [OMakefile]
> # set EPSTOPDF to "epstopdf" on Windows, to "sh epstopdf" on OS X
> %.pdf: %.eps
>  $(EPSTOPDF) $<
> 
> USEPDFLATEX=true
> LaTeXDocument(a, $(EMPTY))
> a.pdf: x.pdf
> [/OMakefile]
> 
> Typing "omake a.pdf" sometimes results in pdflatex running *before*
> epstopdf, resulting in a failed build.  "omake -k a.pdf" (or modifying
> a.tex to not actually depend on x.pdf) allows x.pdf to be built (after
> pdflatex runs).
> 
> As I mentioned, this seem to be non-deterministic.  The problematic
> behaviour seems to happen more often when the last three lines of the
> OMakefile actually appear in a .SUBDIRS OMakefile.
> 
> Thanks.
> _______________________________________________
> Omake mailing list
> Omake at metaprl.org
> https://lists.metaprl.org/mailman/listinfo/omake
>