>>>>> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes:
[ This is a reply to some pretty old email. As is my habit. ] Harlan> I'm working on a project where Somebody decided it would be a Harlan> feature to hack the automake templates to permit subdirs to be Harlan> built in parallel. Ok. Harlan> I'm wondering if there is benefit to allowing SUBDIRS to be Harlan> build in parallel by option (or default), and wondering if Harlan> it's possible, reasonable, and not too difficult to use Harlan> dependency lines in the "parent" Makefile.am to control Harlan> serialization, ie: I've actually considered this from time to time. It isn't an unreasonable idea. It would definitely have to be explicitly requested, though. We've long promised that SUBDIRS will be built in order. Lots of packages depend on this. Harlan> SUBDIRS = include lib bar baz foo Harlan> lib: include Harlan> bar baz foo: lib I suppose what we could do is have a new rule for each subdir: all-recursive-include clean-recursive-include ...: cd include && $(MAKE) ... Then from a specification of subdir interdependencies we could generate the exhaustive list. In Makefile.am: lib-subdir: include-subdir In Makefile.in: all-recursive-lib: all-recursive-include clean-recursive-lib: clean-recursive-include ... Perhaps there's some cleaner way. I don't know, I'm just writing this off the top of my head. Hmm, the clean dependencies would be tricky. Right now we run clean rules in the opposite order as build rules. The gcc top-level Makefile already does something like this. It isn't as robust as what we'd require for automake. One question I have is whether this is actually worth the extra hair. How much parallelism do we really lose with the current implementation? How much does it slow down the build? These questions implicitly assume that the primary benefit of this approach is improved performance. Are there other benefits? Anyway, if the benefit is substantial this would make a good feature-request PR. If there's no benefit, it may be better to drop it. Tom