>>>>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> 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?