[m-dev.] mmake realclean in the runtime directory

Warwick Harvey wharvey at cs.monash.edu.au
Mon Aug 23 15:28:18 AEST 1999


Mark Brown wrote:
> Maybe there is a much simpler solution, but I can't see it.  And
> thinking about recursive makes makes my brain hurt.  ;-)

No kidding...  In particular, it seems one cannot have (e.g.) the 
recursively invoked "realclean" target be the same as the one you would 
normally invoke in that subdirectory (unless Make is being way too smart).  
You've probably figured this out already, but forgive me for going slow 
while by brain tries to catch up.  :-)

Consider a directory A, with subdirectory B.

1) If one invokes `realclean' in A, then one wants the effect of both 
`clean' and `realclean' in both A and B.

2) If one invokes `clean' in A, then one wants `clean' in both A and B.

3) If one invokes `realclean' in B, then one wants the effect of both 
`clean' and `realclean' in B.

Now, 2) implies that A:clean should invoke B:clean, while 3) implies that 
B:realclean should also invoke B:clean.  1) _suggests_ that A:realclean 
should invoke A:clean and B:realclean, but that (I believe) would result in 
B:clean being called twice.  This may not be that big a deal, unless B has a 
subdirectory C...  ;-)

This seems to indicate that A:realclean should either invoke a non-recursive 
version of A:clean, or a version of B:realclean which does not invoke 
B:clean.

Conclusion: you don't want the user to add extra dependencies and/or rules 
to the `clean' and `realclean' targets, or they'll get "lost" by a proper 
recursive implementation.  So it seems like adding them to `clean_local' and 
`realclean_local' might be the right thing to do after all (i.e. I withdraw 
my earlier suggestion that this was the wrong thing to do, and support your 
proposed fix to Zoltan's problem...  ;-).

Warwick

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list