On Tue, Apr 02, 2002 at 12:39:00PM -0800, Paul Eggert wrote:
> 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.
Hey, that's cool! Even if configuration is done at several
levels, this generalizes cleanly, I think: in any directory with
a configure script (i.e. $top_builddir, plus any directory
referred to in the AC_CONFIG_SUBDIRS() tree), "make distclean"
cleans configure-time stuff; in any other directory, it just does
"make clean".
If a user types "make distclean" in an AC_CONFIG_SUBDIRS()
directory, they'll have to rerun configure, either in that
directory or back up at top_builddir. That's still a bit
awkward, but better than the status quo, I think.
It does violate the PoLP (principle of least surprise) again,
though, to have distclean sometimes doing one thing and sometimes
another.
[N.B.: The rest of this message does not apply if the above
suggestion of Paul's is taken. Doing so would complicate the
rule, but would also sidestep the problem.]
> 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.
The rule should be:
A directory needs to have "make distclean" run in it
iff it contains a Makefile.
Thus:
- Makefile should be the first file generated by config.status
(the AC_CONFIG_FILES() order should be shuffled accordingly
- Makefile should be the last file deleted by "make distclean"
> 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.
Yeah, in theory there's a race condition. But if they're removed
last and second-last, in the same "rm" command, the likelihood of
being interrupted in *just* the wrong place is vanishingly small.
More of a problem, I suspect, is that the user can manually
remove a Makefile; that violates the rule, and there's not much
we can do about it.
I guess that's an argument for having the top-level
"config.status --distclean" clean the whole tree ... or for this:
>
> 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.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. [EMAIL PROTECTED]
| | /
"Outlook not so good." That magic 8-ball knows everything!
I'll ask about Exchange Server next.
- Anonymous
