On 12/12/06, Alexey Neyman <[EMAIL PROTECTED]> 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 _______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
