Re: ac-lang-compiler-gnu.patch

[Akim Demaille]

>>>>> "Pavel" == Pavel Roskin <address@hidden> writes:

>> AU_ALIAS(ac_cv_prog_gcc, ac_c_cv_compiler_gnu)
>> 
>> (plus the quotes, of course ;)

Pavel> I don't think that everybody will run autoupdate on their
Pavel> configure.in.  There are several cases when complete switching
Pavel> is not feasible (think of Libtool).

Err, AU_ALIAS is more than merely for autoupdate.  It is also
equivalent to

define(ac_cv_prog_gcc, ac_c_cv_compiler_gnu)


Pavel> I realize how painful it is when your patch is rejected, but
Pavel> after some consideration I'm feel even worse about such changes
Pavel> that I felt yesterday.

I understand this.  And I'm OK with having patch rejected/discussed,
thanks for taking care of me :)  What does preoccupy myself is the
factorization of Autoconf, and the fact that history clutters
Autoconf.  There are great challenges ahead, in particular in the area
of multiple languages support.  I'm concerned by the lack of
uniformity there.  This is why whenever I can, I factor out the code.

Here, I understand your concern, but unless you show me a configure.in
which semantics has changed because of my patch, I can't understand
your resistance.  But I guess it is by misunderstanding of AU_ALIAS.


Pavel> If you can avoid renaming the variables (by any means) then
Pavel> it's Ok to apply now. If you cannot or don't want to preserve
Pavel> the traditional names please delay the patch for after 2.50.

Of course I can avoid this.  But, as I wrote, I don't wish to.  If my
``clean'' uniform name scheme does fail, then I will backtrack.

Fundamentally my proposal is:
- oriented towards the future
  use a simple name scheme that freezes us from multiplying
  AC_LANG_ABBREV like macros
- oriented towards the past
  relate old names to new names for both autoconf and autoupdate.

There is definitely a big bug in my proposal: picky configure.in
writers may have doubly quoted ac_cv_prog_gcc somewhere.  I just don't
imagine we will ever find this case.


Pavel> Otherwise the incompatibility between 2.13 and 2.50 can reach
Pavel> the level when people will refrain from using
Pavel> Autoconf-2.50. This is a minor change, but many minor changes
Pavel> create big problems.

Please, I know Pavel, I know, I know.  I agree from the start I should
have kept a safety net for people who peek in the cache variables, but
my scheme is more bugward compatible than you seem to believe.

I still consider that incompatibilities between 2.13 and 2.50 are bad.
I will certainly not fight hard for dirty configure.ins, but
preserving the semantics of regular configure.in does matter to me.


        Akim