[Top][All Lists]

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

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

From: Akim Demaille
Subject: Re: RFC: ./configure or ./config.status --clean
Date: 02 Apr 2002 18:57:05 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp)

>>>>> "Paul" == Paul Eggert <address@hidden> 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

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.

reply via email to

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