If I understood what you are asking you can do it with something like this:
# dependencies for "clean" (this is surely marco-izable somehow?)
all_clean= clean.pre clean.post clean.do
.PHONY: ${all_clean}
clean: ${all_clean}
clean.pre:
clean.do: ${SUBDIRS} | clean.pre
clean.post: | clean.do# repeat above for build config install, etc...
# general subdirs rule
${SUBDIRS}:
@echo $@ ${MAKECMDGOALS}
# target specific pre and post rules install.pre: @echo $@
clean.post:
@echo $@If you do something like "make clean install" it messes it up a bit, so you have to limit yourself to one target per make invocation. (there is a partial way around this if you get rid of the general SUBDIRS rule, and replace with SUBDIRS.clean, SUBDIRS.install, etc..., but even then I think there is no guarentee that the clean.post will happen before the install.pre for example)
Best regards, Ian
From: "Robert P. J. Day" <[EMAIL PROTECTED]> To: GNU make mailing list <[email protected]> Subject: more general question on parallelization and checkpoints Date: Mon, 7 Mar 2005 17:29:37 -0500 (EST)
i've been messing with this all afternoon, and i can't help but think there's an easier way to do this than what i've come up with. here's the general problem, which is an extension of what i asked about earlier.
i have a top-level makefile which has to support multiple subdirectories and multiple actions -- for example:
SUBDIRS = d1 d2 d3 d4 ACTIONS = clean configure build install
now, i know there are a couple different ways to write the recursive processing. the first doesn't support parallel processing (all of the following is drastically simplified so, yes, it's kind of pseudo-code):
${ACTIONS}: for d in ${SUBDIRS} ; do \ ${MAKE} -C $$d $@ ; \ done
the second technique is what i've been using until now -- to support *potential* future parallelization:
.PHONY: ${SUBDIRS} ${SUBDIRS}: ${MAKE} -C $@ ${MAKECMDGOALS}
now, here's the problem. i'd like to be able to define, for any of the actions, a possible pre-processing and possible post-processing target. as an example, say all of my subdirectories have an "install" target that installs stuff into a single destination directory.
however, before *anyone* can do an install, i might want to remove the existing dest. directory and initialize a new one. so i would have an "install" pre-processing target that would have to be run before *any* subdirectory install target is processed.
similarly, perhaps i want to define an install *post*-processing step -- maybe run through the entire output directory, strip executables, fix symlinks and so on. (yes, that could possibly be done by *each* install sub-target, but there are some cases where it's just *way* easier to wait until all children have done their install, then take care of it at the end.)
i'm trying to do this with the second (parallelizable) approach above and it's just getting ugly. at this point, i'm ready to throw in the towel and go back to the non-parallelizable loop approach, which would certainly be easier to modify.
am i asking too much here? is there a standard way to do this sort of thing?
rday
p.s. to summarize, in a perfect world, each sub-directory would be able to be processed in parallel with every other sub-directory but, if i define a pre-processing step for *any* action, then no sub-directory would be allowed to start processing that action until the pre-processing step was complete. and the pre-processing step would *only* be run if at least one subdirectory was processing that action. (i.e., there would be no point running the "install" pre-processing step if no subdirectory was processing the "install" action.)
similarly, if i defined a post-processing step for an action, then that post-processing would not be allowed to run until all subdirectories has processed that action.
i originally thought this wasn't going to be that difficult, but i'm rapidly changing my mind.
thoughts?
_______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
_________________________________________________________________
Bored at work? Chat, flirt and play with MSN Messenger - FREE download! http://messenger.msn.co.uk/Beta/Default.aspx
_______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
