bug-make
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]