[m-dev.] mmake realclean in the runtime directory
Warwick Harvey
wharvey at cs.monash.edu.au
Fri Aug 20 15:33:26 AEST 1999
Zoltan wrote:
> The realclean target now depends on realclean_local and thus on clean_local,
> but does not depend on the clean target. Is this intentional? In the runtime
> directory, the realclean target doesn't have an explicit dependence on clean,
> since (I believe) it used to have a dependence in Mmake.rules. As a result,
> doing a realclean does not actually remove the object files.
Normally (in a standard "Makefile") one has to declare the dependence of
`realclean' on `clean' explicitly. It appears this is also the case in
Mmakefiles if one wishes to redefine `clean'. It's not clear whether this
is intentional or not. The realclean_local target obviously really does
depend on the clean_local target, but it's conceivable the user may wish to
not have the realclean target depend on the clean target. This stuff was
implemented with recursive cleans in mind, so there may be something there,
but I can't think of anything right now which would need this lack of
dependency but still work right in other cases.
Maybe Mark (who implemented the local targets) can shed some light? I can't
find any messages about it in the web archive (though I'm pretty sure I saw
some at the time).
> BTW, mmake still has lots of stuff about programs that we deleted a while
> ago, msc etc.
Yes, same goes for the tools/bootcheck script (though that is of course less
user-visible).
Some of this support is worth keeping. For instance, continuing to delete
the Prolog files in the clean targets is probably worth maintaining until at
least the next release. That way, if people have such files lying around
when they upgrade, they still get cleaned up by the new version.
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