Re: "unparallelizing" a recursive make

[Dan Kegel]

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 
http://kegel.com/academy/getting-hired.html