>>>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
>> 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 Paul> You read my mind! :-) Still (but I'm not longer trying to convince, I'm just expressing my opinion), one of the dangers of the GNU Build System is the mix of compilations on different arch. To protect the innocents, having distclean really do the distclean seems sane to me. Or maybe, have the distclean in subdir end with a message stating that distclean is preferred in the top level. But that's Automake matter, no longer ours. >> but... It imposes quite some complications to maintain this >> possibility, Paul> What complications are these? Paul> It's OK with me if "make distclean" in a subdirectory is Paul> equivalent to "make clean", and you need to do "make distclean" Paul> at the top level to clean out all the stuff built by "configure" Paul> at the top level. This sounds to me like the right thing to do, Paul> in the usual case where all configuration is done at the top Paul> level. Paul> I hope this removes the complications.... This seems like to best shot! Unless someone raises the hand against this idea, it seems to me to be the best compromise. distclean, by nature, is package wide, while clean is directory wide. I like that! >> 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. Paul> That would be one way to do it. But if it's done that way, the Paul> Makefile should still be the last thing to be removed. Sure! Paul> Perhaps "make distclean" should invoke "./configure --clean", Paul> which would take care to remove the Makefile last. Agreed. And config.status too. Paul> This avoids the problem since "configure" is not removed. But Paul> once we have "./configure --clean", I don't see the point of Paul> having "./config.status --clean". As far as I can see, anybody Paul> who wants to invoke the latter will prefer invoking the former. Paul> I don't think it _hurts_ to have "config.status --clean", but I Paul> don't see why anybody would want to use it. I agree. In addition, there is some weak desire in Autoconf to hide the existence of config.status. I broke this somewhat with the `config.status: creating foo' instead of `configure: creating foo' as in 2.13. 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> The latter. I was referring to "make distclean" being invoked Paul> in a directory with a subdirectory. The directory might not be Paul> at the top level. Given the present state of proposal, it seems that this case no longer exists. Or rather, it is only a matter for the clean target.
