automake
[Top][All Lists]
Advanced

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

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


From: Eric Siegerman
Subject: Re: RFC: ./configure or ./config.status --clean
Date: Tue, 26 Mar 2002 15:15:32 -0500
User-agent: Mutt/1.2.5i

On Tue, Mar 26, 2002 at 10:30:22AM -0800, Paul Eggert wrote:
> > 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.

Another possibility is to do the cleaning in the Makefile as it's
always been done, but have config.status provide the list of
files.  Something like an "@configure_targets@" macro for
config.status to replace -- the catch being that, unlike other
macros, this one's value is customized per directory.  So every
Makefile.in (Automake-generated or otherwise), can just say:
        distclean-whatever:
                ....
                -rm -f @configure_targets@

This accomplishes the goal of removing knowledge of Autoconf from
inside Automake, while sidestepping all these other decisions :-)


> 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.

Easily accomplished, if it's desirable, by making
@configure_targets@ expand to a list of all possible targets in
that directory, not just the ones created in the current
configuration.

But deleting all possible targets (however it's done) carries a
risk, in theory.  Suppose that in my configuration, the file
"foo" isn't generated.  Suppose further that I create a file by
that name myself.  I really don't want distclean to nuke it!
Which way to decide this depends, it seems to me, on how likely
this scenario is in practice.


> > My opinion is that [distclean] 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'.

My suggestion implicitly agrees with this -- but only by not
making the decision at all, and just leaving the timing to the
distclean target.  Autoconf decides *what* to clean, but *when*
to clean it is up to the writer of Makefile.in, whether that be
Automake or a human.

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

Yes, please!

> If "rm Makefile" is the the last thing that "make distclean" does,

i.e. autoconf guarantees that Makefile be the last file listed
in @configure_targets@, and Automake put that macro at the end
of distclean-local or whatever it's called,

> then this alternate proposal is more robust than the method you
> proposed.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
"Outlook not so good."  That magic 8-ball knows everything!
I'll ask about Exchange Server next.
        - Anonymous



reply via email to

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