[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AC_LANG_COMPILER_REQUIRE problem
From: |
Stepan Kasal |
Subject: |
AC_LANG_COMPILER_REQUIRE problem |
Date: |
Thu, 10 Dec 2009 16:54:20 +0100 |
User-agent: |
Mutt/1.5.19 (2009-01-05) |
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
- AC_LANG_COMPILER_REQUIRE problem,
Stepan Kasal <=