Re: AC_OUTPUT_COMMANDS

[Akim Demaille]

>>>>> "Ralf" == Ralf Corsepius <address@hidden> writes:

Ralf> => Random (== BROKEN) behaviour.

No, undefined == undefined.  

This has *never* been part of Autoconf, and the lack of sense of
2.13's answers are quite a demonstration of it.

My sentence was `Garbage in, garbage out'.

Even if widely used (where can one find that config-ml.in?), it's
wrong.  AFAIK GCC does not maintain bugward compatibility either.


Ralf> Then it was a good accident and the current behavior should be
Ralf> regarded as a regression.

Sorry, I can't accept this argument because I will not accept having
$srcdir and @srcdir@ having different meanings.  Had the behavior of
2.13 being meaningful, then yes.  But it's not the case.  That
$top_srcdir can be different from srcdir inside configure is dumb.

I'm ready to help on config-ml.in and whatever you want to make them
compatible with the two Autoconves, but Autoconf has enough scars as
is.


Ralf> If you want to avoid trouble, them they the behavior should at
Ralf> least be deterministic (More precisely: CONFIG-FILES must not
Ralf> alter variables users explicitly set in INIT of AC_CONFIG_*).

Again, I disagree: it *does not matter* just because this is an
internal detail.  I will not struggle to have ac_dir and ac_mkdir_dir
etc. variables preserved through out this section, because it's
Autoconf's private internal guts.

If I decide someday to use date or $RANDOM to set top_srcdir, then
it's fine with Autoconf.

But I agree ``assert (test -f $srcdir/configure.in)'' through out
configure.


>> In which case it seems to me there is only one definition which
>> makes sense (to me): srcdir and top_srcdir share the very same
>> value: they point to the directory holding the currently running
>> configure.in.
Ralf> Agreed.

Great :)

Ralf> * The CONFIG_FILES section trashes variables a user explicitly
Ralf> sets in AC_CONFIG_COMMANDS. 

Huh?  I'll reread your message about that.  But of course if the user
uses Autoconf variables... :)

Ralf> * srcdir given random contents in AC_CONFIG_COMMANDS 

Should remain constant to point to configure.in.


>> So I think the case is closed.  ?
Ralf> No, I disagree. (Check out config-ml.in and see how it is
Ralf> applied with automake in newlib.)

Where is it?