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

[Mark Anthony BROWN]

Fergus Henderson writes:
> 
> On 23-Aug-1999, Mark Anthony BROWN <dougl at cs.mu.OZ.AU> wrote:
> > 
> > I agree that requiring the user to know about the local targets is
> > a drawback of the current design.  But, I couldn't figure out how to
> > avoid this and still achieve the other aims, which included being
> > able to have `clean' and `realclean' both invoke mmake recursively.
> 
> Is there any reason why we can't add
> 
> 	realclean: clean
> 
> in scripts/Mmake.rules?
> 
> It would be a little inefficient, since `mmake realclean' in a directory
> with subdirectories would first invoke a recursive `mmake clean' and then
> invoke a recursive `mmake realclean'.

That is the reason.

>  However, that is probably a reasonable
> price to pay for keeping the user interface simple (the user doesn't
> *need* to know about `clean_local' etc.) and for preserving backwards
> compatibility with existing Mmakefiles.

It would be less reasonable in the case that some of the
subdirectories also had subdirectories (and so on).

> 
> If you want to preserve the possibility of a more efficient `mmake realclean'
> for expert users, we could make it configurable:
> 
> 	ifneq($(DISABLE_REALCLEAN_DEPENDENCY),yes)
> 	realclean: clean
> 	endif
> 

Even novice users will want the more efficient `mmake realclean'
if they use it in the toplevel directory of

    some_package/the_novice_got/off_the_web/which_has_many_dir_levels ...

which is a pretty bad worst-case, IMHO.

If you still think it would be better to add the dependency, though,
then I have no further objections.  Incidentally, my personal
preference would probably be to have `clean' and `realclean'
targets which act in the local directory only, and `clean_rec'
and `realclean_rec' which also recurse.  Of course, this is not
backwards compatible either.

Cheers,
Mark
-- 
Mark Brown, PhD student            )O+  |  "Another of Fortran's breakthroughs
(m.brown at cs.mu.oz.au)                   |  was the GOTO statement, which was...
Dept. of Computer Science and Software  |  uniquely simple and understandable"
Engineering, University of Melbourne    |              -- IEEE, 1994
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------