help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Improvement on parallel make


From: Alexey Neyman
Subject: Re: Improvement on parallel make
Date: Mon, 11 Dec 2006 17:19:22 +0300
User-agent: KMail/1.6.2

On Monday 11 December 2006 16:40, Philip Guenther wrote:
> On 12/11/06, Alexey Neyman <address@hidden> wrote:
> ...
> > 3. BSD make associates the .WAIT semantics with a target, not with 
a
> > dependency.
> 
> To clarify, are you saying that the .WAIT has no effect unless the
> target whose dependency list it appears in is *somewhere* in the
> dependency tree of the targets that make is actually building in 
> this run?

No. I meant that for the following Makefile:

<<<
foo: bar .WAIT baz
fum: bar boo
fun: baz buu
<<<

the command "make -j 4 fum fun" will still serialize the "bar" and 
"baz" targets, with "bar" completed before "baz" is started. Note 
that the targets command line does not include "foo" - which 
specifies the .WAIT behavior.

BSD make behaves so, because it records the "bar" target as a 
predecessor for the "baz" target. If both targets are to be remade, 
they will be serialized. If only one is to be remade, there will be 
no serialization imposed.

> Which of .WAIT's semantics are actually documented goals and which 
> are just side-effects of how the BSD make was, in general,
> implemented? 
> If those can't be disentangled, then the whole concept actually 
> seems kind of suspect to me.  As is, it's apparent
> action-at-a-distance would seem to invite creation of unmaintainable
> makefiles.

From the man page in FreeBSD, I conclude that such behavior matches 
the design goal. I'd guess that .WAIT in the example above can be 
regarded as "bar and baz cannot be run in parallel" specification. In 
this regard, it is a property of the "bar" and "baz" targets - there 
is no action-at-a-distance in this case.

Regards,
Alexey.

-- 
Let us help you.  Let us heal you. Let us love you.
                        -- Pkunks, SC2




reply via email to

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