Re: RE: make -j and multiple targets

[Patryk Zadarnowski]

On Thu, 6 Sep 2001 02:17:26 -0700, "Howard Chu" <address@hidden> wrote:

> > -----Original Message-----
> > From: address@hidden [mailto:address@hidden Behalf Of
> > Peter Gammie
> 
> > g'day,
> >
> > i'm using make 3.79.1.
> >
> > if i write a rule like so:
> 
> These rules don't accurately describe the dependencies that you're dealing
> with.
> If you analyzed your actual order of events, you wouldn't have this problem:
> 
> lexer.c: lexer.l
>       flex -t lexer.l > lexer.c
> 
> lexer.h: lexer.c
>       genHeader.pl lexer.l

That's what I've pointed out to Pete, but while we've got your attention,
I'll push the point a little further.

Assume for a moment that the original makefile reflects the true
dependencies, i.e. that we're dealing with a command that takes a
single input file and generates multiple output files (like flex.)
Writing "<outputs>: <inputs>" works, but, as Pete mentioned,
introduces a race condition and occassionaly results in multiple
executions of the command. I would love to see this problem rectified
(by placing all the outputs in a single node of the dependency graph
with the update time of the youngest of the outputs), as there are
scenarios when the current behaviour is a serious problem.

In particular, I regularly compile Haskell programs using GHC. For
each input file, GHC generates two outputs: the object file and the
"interface" file, sort of like an automatically-generated header.
Therefore, the _correct_ way of writing the dependency would be:

        xxx.o xxx.hi: xxx.hs
                ghc -o xxx.o xxx.hs

This is OK, but, in most projects, there will be multiple other
targets (object files) dependant on "xxx.hi", and other targets
dependant on the "xxx.o", so "make" occassionaly executes "ghc"
twice. Normally, nobody would notice, if not for the fact that, on a
typical hardware, "ghc" takes about 5-10 minutes to compile any but
the most trivial "xxx.hs". This turns the proverbial cup of coffee
into a whole expresso machine, and I did see build times extended by
30 minutes and more because of the quirk.

Incidentally, this is a problem with both GNU make and bmake.

Just throwing my 2 cents (+GST) worth.

        Pat.