[Top][All Lists]

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

Re: "unparallelizing" a recursive make

From: Dan Kegel
Subject: Re: "unparallelizing" a recursive make
Date: Sun, 12 Jun 2005 17:36:06 -0700
User-agent: Mozilla/4.0 (compatible;MSIE 5.5; Windows 98)

Darin Johnson wrote:
I've been playing around with distcc to see how useful it might be in our
cygwin environment.  but I'm seeing too much parallelism with regards
to recursive sub-makes.  The problem is that the outputs from different
subdirectories get mixed together, which can be confusing when trying
to see what's going on.

That's par for the course.  If you run into errors,
just run without distcc to get a clean log.

(Or do what I did: change your project's .c -> .o
rule to redirect stdout and stderr to .log.
Then do a find and stitch together all the .log files
later.  It's annoying and time-consuming, but
for some projects it's worth the trouble.)

Another problem is that if the build may end
after an error in one submake, yet another submake continues to
build in the backround even after returning to the command line.

That sounds like a classic cygwin problem;
I've seen that happen without distcc.

What I'd like to be able to easily do is have all the makes serialized
while allowing parallelism within each individual subdirectory.  There's
plenty of parallelism to go around even when limiting it this way.
I could go back to the standard for-loop method as one option, or
I could add a "MAKEFLAGS += -j4" inside the makefile rather than on
the command line, but I'm hoping for a cleaner solution if anyone
has suggestions.

Well, if you ask me, the right solution is to rewrite
your project's build system to get
rid of the recursive sub-makes.  As we all know,
"recursive make is considered harmful".
- Dan

Trying to get a job as a c++ developer?  See

reply via email to

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