Re: Parallel build dependency locking

[John Graham-Cumming]

On Thu, 2005-06-09 at 19:11 -0400, Christopher Sean Morrison wrote:
> That may very well be true, but in this particular instance, the 
> workaround/solution to use the all-am did nothing to change which 
> targets were reached.  It merely avoided a secondary invocation of make 
> (that did the exact same thing, reached the same targets/rules in 
> parallel, etc).
> 
> There is already support for processing multiple targets simultaneously 
> albeit through some form of locking to ensure that each 
> dependency/target is being handled by only one of the -j workers (in 
> that process).  That is the simple nature of a -j parallel build.  All 
> I'm suggesting is a means to extend that same locking mechanism on 
> dependancies being processed by child, sub-process, or otherwise 
> concurrent makes also.

(Disclaimer: I am not a GNU Make developer, but I spend all my time
dealing with parallel builds in my day job at Electric Cloud.)

What you are suggesting is, no doubt, possible but you are asking for
locking on a target across independent make processes.  Clearly, one
could implement locking of that form (although doing it on every
platform that GNU Make supports might be tricky).

However, I think it's the wrong solution to your problem.  It appears
that what you want to do is speed up your build, and you've chosen to do
that by running a parallel build.   If you want to do that then there
are a couple of necessities: you need to make sure that there are no
missing dependencies and that nothing is built twice.

Neither seem, to me, to be GNU Make's responsibility, and implementing
locking would just mean that you allow your build to make targets more
than once.  Isn't the right solution (if your goal is speed) to only
build things once?

John.