AC_LANG_COMPILER_REQUIRE problem

[Stepan Kasal]

Hello,

this mail contains a description of possible bug and my ideas about
possible fixes.  I plan to write the patch but advices are welcome.

I was confronted with an issue with code like this:

AC_DEFUN([MY_CHECK], [
  # something
  AC_PROG_CC
  AC_COMPILE_IFELSE(...)
])
AC_INIT(...)
..
MY_CHECK
..
AC_OUTPUT

(And likewise for C++ and other languages.)

When this is processed with autoconf >= 2.64, AC_PROG_CC is expanded
twice:

The call inside MY_CHECK is expanded.

Later on, AC_PROG_CC is m4_required from AC_LANG_COMPILER(C) that is
required from AC_COMPILE_IFELSE.  This leads to an expansion of
AC_PROG_CC that is places before the whole MY_CHECK expansion.

With Autoconf 2.63, this indirect expansion did not take place,
because of a bug in the its m4_require implementation.  But since
AC_LANG_COMPILER(C) is equal to AC_PROG_CC, things happened to work
anyway.

Current Autoconf rightly warns about the duplicate expansion.
Moreover, the place marked "something" in the example sometimes
manipulates CFLAGS; with the duplicate expansion, this cames in late,
when AC_PROG_CC has been already run.

It is understandable that users expect the above example to work.
(Telling them to use m4_define does not help; this may happen in a
deeper structure of macro calls; perhaps MY_CHECK is even
AC_REQUIREd.)

To fix this, the requires at the beginning of AC_COMPILE_IFELSE
should understand that AC_LANG_COMPILER(C) has in fact already been
expanded.  I am considering several ways to implement it:

1) AC_PROG_CC would call AC_PROVIDE([AC_LANG_COMPILER(C)]) at the
end, with a huge comment "this is valid only because
AC_LANG_COMPILER(C) is equal to AC_PROG_CC.
(And likewise for other languages.)

2) doing things the other way round: AC_PROG_CC would call macro
AC_LANG_COMPILER(C), which would then contain the real body of
AC_PROG_CC.

3) designing a general mechanism to tell that macros are equivalent
for m4_require, something like
    m4_defun_alias([AC_LANG_COMPILER(C)], [AC_PROG_CC])

4) changing the interface for for language implementations in
Autoconf.
For example, instead of AC_DEFUN of AC_LANG_COMPILER(XYZ),
the language implementation would m4_define macro
AC_LANG_COMPILER_REQ(XYZ) that would be allowed to contain one name
of a macro that need to be AC_REQUIREd before the XYZ compiler is
used.  Macro AC_LANG_COMPILER_REQUIRE would call m4_defn to get the
name and then would work with it.
Note that all AC_LANG_COMPILER(XYZ) macros currently contain exactly
one AC_REQUIRE call.

At the moment of sending this mail, it seems to me that 4) could lead
to the cleanest implementation, but any corrections/advices are very
welcome.

Have a nice day,
        Stepan