[Top][All Lists]
[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.