automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Parallel builds and SUBDIRS


From: Tom Tromey
Subject: Re: Parallel builds and SUBDIRS
Date: 17 Aug 2002 18:33:46 -0600
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

>>>>> "Harlan" == Harlan Stenn <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]