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

[Akim Demaille]

>>>>> "Paul" == Paul Eggert <address@hidden> writes:

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

Paul> You read my mind!  :-)

Still (but I'm not longer trying to convince, I'm just expressing my
opinion), one of the dangers of the GNU Build System is the mix of
compilations on different arch.  To protect the innocents, having
distclean really do the distclean seems sane to me.  Or maybe, have
the distclean in subdir end with a message stating that distclean is
preferred in the top level.  But that's Automake matter, no longer
ours.

>> but... It imposes quite some complications to maintain this
>> possibility,

Paul> What complications are these?

Paul> It's OK with me if "make distclean" in a subdirectory is
Paul> equivalent to "make clean", and you need to do "make distclean"
Paul> at the top level to clean out all the stuff built by "configure"
Paul> at the top level.  This sounds to me like the right thing to do,
Paul> in the usual case where all configuration is done at the top
Paul> level.

Paul> I hope this removes the complications....

This seems like to best shot!  Unless someone raises the hand against
this idea, it seems to me to be the best compromise.  distclean, by
nature, is package wide, while clean is directory wide.  I like that!



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

Paul> That would be one way to do it.  But if it's done that way, the
Paul> Makefile should still be the last thing to be removed.

Sure!




Paul> Perhaps "make distclean" should invoke "./configure --clean",
Paul> which would take care to remove the Makefile last.  

Agreed.  And config.status too.

Paul> This avoids the problem since "configure" is not removed.  But
Paul> once we have "./configure --clean", I don't see the point of
Paul> having "./config.status --clean".  As far as I can see, anybody
Paul> who wants to invoke the latter will prefer invoking the former.
Paul> I don't think it _hurts_ to have "config.status --clean", but I
Paul> don't see why anybody would want to use it.

I agree.  In addition, there is some weak desire in Autoconf to hide
the existence of config.status.  I broke this somewhat with the
`config.status: creating foo' instead of `configure: creating foo' as
in 2.13.


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> The latter.  I was referring to "make distclean" being invoked
Paul> in a directory with a subdirectory.  The directory might not be
Paul> at the top level.

Given the present state of proposal, it seems that this case no longer
exists.  Or rather, it is only a matter for the clean target.