help-make
[Top][All Lists]
Advanced

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

Re: Semi-Parallelizing


From: Paul Smith
Subject: Re: Semi-Parallelizing
Date: Tue, 16 Dec 2008 13:59:44 -0500

On Tue, 2008-12-16 at 09:37 -0600, EXT-Pennington, Dale K wrote:

> LIB_DIRS = a b
> SRC_DIRS = c d
> 
> $(SRC_DIRS) : $(LIB_DIRS)
> 
> $(LIB_DIRS) :
>       gmake -C $@ -j 1
> 
> $(SRC_DIRS) :
>       gmake -C $@
> 
> 
> Would this do what I described above ? 

Well, you MUST always use the $(MAKE) variable, never a command like
"gmake", if you want parallelism to work.

But yes, setting -j1 on the command line will override any inherited
setting and disable parallel builds.

> all : $(EXE_NAME) <possibly more>
> 
> $(EXE_NAME) : <dependences>
>       <commands to make EXE_NAME>
> 
> clean_objs :
>       -rm -f $(OBJS) $(DEPFILES)
> 
> clean : clean_objs
>       -rm -f $(EXE_NAME) ...
> 
> 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). 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)

I think the best way to do this is recursion, although I'd use it in all
lines:

        CM:
                $(MAKE) clean
                $(MAKE) all
                $(MAKE) clean_objs

Alternatively you could create variables that contain the commands to
run, then use those in various places to avoid duplication.






reply via email to

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