Re: Improvement on parallel make

[Philip Guenther]

On 12/12/06, Alexey Neyman <address@hidden> wrote:
> There may be cases when it doesn't work, however. E.g. the 'ar' tool
> does not lock the archive while updating it. Thus, running 'ar' on
> the same archive concurrently may corrupt it.

The problem there is to tell make that a set of targets cannot be
built concurrently.  If you use .WAIT to do that, you also block
concurrency in the processing of the dependencies of the targets that
can't be performed concurrently instead of just among the targets
themselves.  You also imply a ordering among the targets that isn't
actually necessary, though the effects of that would seem to be
negligible.

Creating the .WAIT hammer so that people can use it on the
"not-concurrently" screw seems like a bad idea.


> Imagine that both local Makefile and Makefiles in subdirectories need
> to update the archive. How do you express it using normal
> dependencies?

In the projects I've worked on, building libraries incrementally has
not been seen as useful.  Instead, they are built in one 'ar'
invocation after all the objects are up to date.  Yes, this means that
changing a single source file results in the entire archive being
removed and reassembled, but strict rules for the separation of
functionality mean that no library is so large that the rebuild is
annoying.  Note that since 'ar' can't be used concurrently for a given
library, the bulk rebuild is actually *faster* than separate 'ar'
invocations for each object.


That said, this does appear to be a real problem.  It appears to me,
however, that .WAIT is *not* the right solution for it, but I see no
point in spending any brain cycles on it until a decision is made
about what the problem is.  Is it just to obtain compatibility with
BSD make (and Sun's dmake)?  Or is to actually solve a problem in
making build setups work when using GNU make's -j flag?  If the
former, then .WAIT is a done deal and I'll shut up.  If the latter,
then some backing up and thinking about how to actually achieve the
goal is necessary.


Philip Guenther