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

[Paul Eggert]

> From: Akim Demaille <address@hidden>
> Date: 26 Mar 2002 10:53:35 +0100
> 
> * 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.

If you do it in "configure", you can successfully run "make distclean"
on one host, even for a build that was done on a different kind of
host.  If I understand things correctly, under the proposed design
"config.status" would not necessarily work on a different host,
because config.status is host-specific and knows only about files that
it created.  In contrast, "configure" is host-generic and knows about
all files that could possibly be created.

Being able to do a "make distclean" from any host is a nice property,
and it argues for doing things in "configure" rather than in
"config.status".

> * top level only?
> Is distclean valid in a sub Makefile?

distclean is a standard GNU make target, so I would think every sub
Makefile should support it.

> What is the semantics then?
> Should it apply to the whole tree, or just the subtree?

My kneejerk reaction is that a sub Makefile should clean the files it
builds, which are normally just the files in its 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.

This is a tricky situation because, under the current Automake regime,
a sub Makefile builds itself (after a bootstrapping process).

If we follow the naive principle "if you build it, you must clean it",
then a sub Makefile should remove itself with 'make distclean'.

What you're saying is that 'configure' and 'config.status
also build 'Makefile', so they should also clean up after themselves
by removing 'Makefile'.  This sounds reasonable to me.

However, you're also saying that a 'Makefile' should not remove itself
with 'make distclean'.  I think this is a bit more controversial,
partly because of the common-sense principle mentioned above, and
partly because there will be a nontrivial software conversion effort
among Autoconf users who do not use Automake.


> it makes make distclean more robust to interruption: until
> ./config.status is really run, the Makefiles are still present.

That's a good point.  However, if ./config.status is interrupted we
would still have the problem.

Can't we achieve this advantage in a better way?  Here's an idea:

  Before "make distclean" descends into a subdirectory, it tests
  whether that subdirectory has a Makefile, and skips the subdirectory
  if the Makefile is missing.

If "rm Makefile" is the the last thing that "make distclean" does,
then this alternate proposal is more robust than the method you
proposed.  That is because "rm Makefile" is atomic.  So it wouldn't
matter when you interrupted the "make distclean"; if there was more
work to do, another "make distclean" would still do it.