[Top][All Lists]

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

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

From: Akim Demaille
Subject: RFC: ./configure or ./config.status --clean
Date: 26 Mar 2002 10:53:35 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp)

In the list of things that we ought to do to de-correlate Automake
from Autoconf, there is the problem of the list of files to remove for
distclean.  For instance, a recent bug report is about the
configure.lineno that configure might create if the shell does not
support $LINENO.  In this case, Automake ``forgets'' to remove that

Of course, I don't think that Automake should know about this file.
In fact, I don't think that Automake should know about any file
created by configure, rather it should ask configure to perform the
tasks related to these files.

So I think we should have something like ./configure --clean, or
./config.status --clean.

* configure or config.status?

It seems much simpler to do that in config.status, since, for a start,
it knows exactly what files were created.  configure should run in
full before knowing what were the created files, hence to be able to
remove them, since there can be runtime decisions.  But configure is
always there, while config.status might not exist.

Of course we can have both.  config.status --clean would really remove
all the files it created, and configure would remove all the files it
can possibly create.

* top level only?

Is distclean valid in a sub Makefile?  What is the semantics then?
Should it apply to the whole tree, or just the subtree?  My opinion is
that it makes sense only in the top level Makefile, were
./config.status resides.  Therefore, the Makefiles would invoke
./config.status only at the top level.  I think this is a good news,
and it makes make distclean more robust to interruption: until
./config.status is really run, the Makefiles are still present.  I
guess I'm not the only one who had a distclean fail at some point, but
then it cannot continue, as it relies on Makefiles which have already
been distclean'ed.

There are probably other questions to ask, but let's go step by step.

reply via email to

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