Re: RFC: ./configure or ./config.status --clean

[Eric Siegerman]

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.        address@hidden
|  |  /
"Outlook not so good."  That magic 8-ball knows everything!
I'll ask about Exchange Server next.
        - Anonymous