[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