[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug #17873] .NOTPARALLEL enhancements
From: |
David Fang |
Subject: |
Re: [bug #17873] .NOTPARALLEL enhancements |
Date: |
Thu, 28 Sep 2006 17:19:12 -0400 (EDT) |
> > In my experience, I frequently build pdf and ps documents from the same
> > latex sources, via latex and pdflatex. Unfortunately, the intermediate
> > auxiliary files they produce are not compatible with each other (latex vs.
> > pdflatex), thus, I use .NOTPARALLEL: foo.pdf foo.dvi, and use a last-build
> > stamp mechanism to clobber the .aux when needed. Everywhere else, I write
> > 'proper' dependencies, and make -j. :)
>
> Thanks for that example. (Though for your specific case, since pdf is
> essentially entropy-coded postscript, you shouldn't need to rerun latex
> to generate it.) I guess if we're stuck with dumb programs that generate
> intermediate files whose names can't be changed on the command line,
> then this sort of approach is the only way out.
Hi,
True. The real reason building dvi and pdf at the same time is a problem
is because they both produce .aux intermediates, which of course, doesn't
work with parallel-make. This is why there are things like 'ylwrap' from
automake (which works wonders for lex/yacc).
> > BTW, this might be off-topic for this thread, but has anyone looked into
> > randomized ordering of dependency-building? (*GASP* why on earth would
>
> Yes, I've suggested this a number of times in the past. Never formally
> in a bug report, but #17881 which I just submitted lists that as well.
Maybe it's time we "use the source" and submit a patch? :)
I remember taking a look at the source where children jobs are dispatched,
but don't recall deciding where/how to hack in random ordering.
Fang