>>>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
Paul> If you do it in "configure", you can successfully run "make Paul> distclean" on one host, even for a build that was done on a Paul> different kind of host. If I understand things correctly, under Paul> the proposed design "config.status" would not necessarily work Paul> on a different host, because config.status is host-specific and Paul> knows only about files that it created. In contrast, Paul> "configure" is host-generic and knows about all files that could Paul> possibly be created. Nice point. Paul> Being able to do a "make distclean" from any host is a nice Paul> property, and it argues for doing things in "configure" rather Paul> than in "config.status". Actually, not really. If you want to remove only what was created, then you have to do it from config.status. If you want to remove everybody, you can from either. >> * top level only? Is distclean valid in a sub Makefile? Paul> distclean is a standard GNU make target, so I would think every Paul> sub Makefile should support it. >> What is the semantics then? Should it apply to the whole tree, or >> just the subtree? Paul> My kneejerk reaction is that a sub Makefile should clean the Paul> files it builds, which are normally just the files in its Paul> subtree. That's really my question. But does it really matter? I mean, 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, but... It imposes quite some complications to maintain this possibility, and I'm not sure it's good. In addition, the semantics of distclean in a subdirectory being so fuzzy (to my eyes), that making it valid only in a top level directory seems reasonable to me. The problem being the last two words, of course :) Paul> However, you're also saying that a 'Makefile' should not remove Paul> itself with 'make distclean'. I think this is a bit more Paul> controversial, partly because of the common-sense principle Paul> mentioned above, and partly because there will be a nontrivial Paul> software conversion effort among Autoconf users who do not use Paul> Automake. I was probably confusing, because I was addressing two different things: 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. 2. Because `distclean' doesn't make a lot of sense to me in subdir, as an additional question, 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. And, as far as Automake goes, I don't think I'm making things worse to its non-users. Nothing changes for them. >> it makes make distclean more robust to interruption: until >> ./config.status is really run, the Makefiles are still present. 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. And if we move this feature to configure, then it is even valid if config.status has disappeared. Paul> Can't we achieve this advantage in a better way? Here's an Paul> idea: 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? 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 agree.
