Re: Semi-Parallelizing

[David Boyce]

On Tue, Dec 16, 2008 at 10:37 AM, EXT-Pennington, Dale K
<address@hidden> wrote:
> We have a top level make that basicallly invokes make on each of the src
> dirs. Right now, we take advantage of the serial nature of make to make
> the library directories before the bin directories, but that can be
> handled by just adding dependencies to show the bin directories depend
> on the lib directories (I think).

This might be trickier than you think - making the literal bin dirs
depend on the literal lib dirs is unlikely to work. You may be able to
work out suitable dependencies between the pseudo-targets representing
those build units.

> The other issue at this level is when
> making the actual libraries, we do not want to do the actual library
> compiles in parallel due to ar issues.

This seems like a rather drastic "solution". If you elaborate on the
"ar issues" a better one may show up.

> So, if I explicitly pass -j 1 in
> the command line to the submake invocation, will that override and
> passed down -j flag from the master make ?

For this I think you might be better served by the .NOTPARALLEL special target.

> At the src dir level, we actually have 3 standard make targets, all,
> which is a strait compile, clean, which removed all compilation
> products, and CM, which is supposed to force a total rebuild of that
> directory, then remove the intermeditate compilation products. In
> general they tend to look like
>
> CM : clean all clean_objs
>
> The real problem child in this case is CM. As long as -j is not
> specified (or is a 1), then the order that gmake issues build requests
> make it work (I am not sure gmake guarantees this, so this may not be
> the safest design anyways).

As I understand it: GNU make does not *guarantee* that targets are
built left to right, in the sense that there's no written standard
which makes the promise. But all make variants have always worked this
way, and the odds of GNU make ever changing are vanishingly small.

> But as soon as we use the -j flag, the CM
> option is clearly broken. So far I have not figured out a way to do this
> without basically duplicating a lot of the targets actions. In
> particular I would prefer not to have to replicate the $(EXE_NAME)
> stuff, and thus far I have avoided recursively invoking make (although I
> guess that might end up being the best option, something like)
>
> CM :
>        -rm -f $(EXE_NAME) $(OBJS) $(DEPFILES)
>        gmake all
>        -rm -f $(OBJS) $(DEP_FILES)

You're already invoking make recursively; it's a recursive build
model. So I don't see anything particularly troubling about this
pattern.

-David Boyce