> From: Akim Demaille <[EMAIL PROTECTED]> > Date: 02 Apr 2002 18:57:05 +0200 > > it makes no sense at all the distclean a single directory, as anyway you > need to rerun config.status to re-enable this directory. Of course, > knowledgeable people will answer that ./config.status foo/Makefile > does it all
You read my mind! :-) > but... It imposes quite some complications to maintain this possibility, What complications are these? It's OK with me if "make distclean" in a subdirectory is equivalent to "make clean", and you need to do "make distclean" at the top level to clean out all the stuff built by "configure" at the top level. This sounds to me like the right thing to do, in the usual case where all configuration is done at the top level. I hope this removes the complications.... > 1. I'm more interested in having a Makefile remove itself without > knowing than with removing itself explicitly. I mean that the > Makefile should not try to learn what is built in its directory > (amongst which there is the Makefile itself). The Makefile should ask > config.status what is to be removed. That would be one way to do it. But if it's done that way, the Makefile should still be the last thing to be removed. > do we still want to enable distclean from a subdir, and if so, would > it be grave that this subdir distclean triggers the top level's > distclean. I think people will be surprised if doing it in a subdir does it for a parent dir. It would be better not to do it at all than to do too much. > Paul> That's a good point. However, if ./config.status is interrupted > Paul> we would still have the problem. > > Nope, as long as config.status is present, it is able to remove the > products. But I was talking about the point of view of the person who types "make distclean". That person should be able to type "make distclean" again, if the first one gets interrupted. Therefore, if "make distclean" invokes "config.status --clean" we have a problem. Either "config.status --clean" removes the Makefile last -- in which case "config.status --clean" does not work properly if reinvoked after being interrupted; or it removes config.status last -- in which case "make distclean" does not work properly if reinvoked after being interrupted. Perhaps "make distclean" should invoke "./configure --clean", which would take care to remove the Makefile last. This avoids the problem since "configure" is not removed. But once we have "./configure --clean", I don't see the point of having "./config.status --clean". As far as I can see, anybody who wants to invoke the latter will prefer invoking the former. I don't think it _hurts_ to have "config.status --clean", but I don't see why anybody would want to use it. > Paul> Before "make distclean" descends into a subdirectory, it tests > Paul> whether that subdirectory has a Makefile, and skips the > Paul> subdirectory if the Makefile is missing. > > I'm not sure to understand the framework you consider here. I'm > interested in the Autoconf feature, and therefore, I don't care much > of what the Makefile itself does. So, are you referring to > config.status --clean being invoked in a subdir? The latter. I was referring to "make distclean" being invoked in a directory with a subdirectory. The directory might not be at the top level. > Paul> If "rm Makefile" is the the last thing that "make distclean" > Paul> does, then this alternate proposal is more robust than the > Paul> method you proposed. That is because "rm Makefile" is atomic. > Paul> So it wouldn't matter when you interrupted the "make distclean"; > Paul> if there was more work to do, another "make distclean" would > Paul> still do it. > > IIUC, you're saying config.status --clean should end with the top > level. I was thinking of "make distclean", not "config.status --clean", though the principles are similar. Also, I was thinking only of "make distclean" at a particular level. I wasn't thinking that "make distclean" in a subdirectory would invoke "make distclean" in a parent.
