[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: Re: RFC: ./configure or ./config.status --clean
Date: Tue, 2 Apr 2002 12:39:00 -0800 (PST)

> From: Akim Demaille <address@hidden>
> 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

> 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

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

> 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

> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]