On Thu, 2010-07-29 at 11:43 +0200, Michele Zamparelli wrote: > I have a makefile which works flawlessly when doing 'clean' and 'all', > but which fails miserably when doing > 'clean all'. > > The reasons is pruning. > A clean subgoal deletes a generated C file (stack.c), which had been > generated earlier on, at dependency inclusion time. > When executing the all target, make eventually tries to build an object > file for a library, assuming that the generated C file is still there.
Yes, that's true. Make always assumes that once it builds a target, that target stays built. It will never try to build the same target twice in the same invocation of the makefile. Your "clean" target has side-effects: it deletes some files that make believes exist... so you're going to run into problems. The simplest way to solve your problem is to use one level of recursion: have top-level rules like "clean" and "all" invoke a sub-make to do their work (actually, you only really need the sub-make for the "all" rule). When you invoke a sub-make to create the "all" target, it will not know that a different make deleted those files just a minute ago. > You will probably have spotted another flaw in this: the dependencies > (gcc --MM) are automatically generated and included even when only 'make > clean' is called, on a directory which is clean already. This can be solved by putting the includes inside a make conditional using the $(MAKECMDGOALS) special variable to see what commands the user ran from the command line. If it's "clean", then don't include the dependencies. > Ideally I would like the 'include' directives to be called only as part > of the 'all' target, but I understand this is conceptually not possible. > Or is it? It's almost impossible to get "make clean all" to work right in a single makefile with a single invocation of make. You can use the sub-make invocation idea I mention above to make this work. Or you can just require people to always run it in two steps "make clean && make all" (you can again check this with MAKECMDGOALS if you want to enforce it). Of course, you could just stop using the auto-generating dependency trick in the first place: it's got a lot of downsides. For an alternative you can start with my document "Advanced Auto-Dependency Generation" on the website below. -- ------------------------------------------------------------------------------- Paul D. Smith <[email protected]> Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist _______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
