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. _______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
