Hi Eric et al.,
The input of AC_COMPILE_IFELSE, AC_LINK_IFELSE, AC_RUN_IFELSE should be a
program. No one prevents a user from writing
AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS])
AC_COMPILE_IFELSE(
[[#include <fcntl.h>
int x = F_DUPFD_CLOEXEC;
]],
[gl_cv_fcntl_dupfd_cloexec=yes],
[gl_cv_fcntl_dupfd_cloexec=no])
But this code does not work: It will for example fail to detect the
presence of F_DUPFD_CLOEXEC on glibc systems. The reason is that the
test program does not see the preprocessor definitions (_GNU_SOURCE,
HAVE_* etc.) created by previous autoconf macro invocations like
gl_USE_SYSTEM_EXTENSIONS.
In other words, the first argument of AC_COMPILE_IFELSE, AC_LINK_IFELSE,
AC_RUN_IFELSE should always be an invocation of AC_LANG_SOURCE or
AC_LANG_PROGRAM, but there is nothing that enforces this.
I find that this is a major pitfall of the AC_*_IFELSE macros. [1]
What can be done about this?
Can these three macros be modified to check their first argument
unexpanded, to see whether it is an invocation of AC_LANG_SOURCE or
AC_LANG_PROGRAM, and give a warning if not?
Or can these macros be modified to check their first argument once it is
expanded, to see whether it contains the string "/* end confdefs.h. */",
and give a warning if not?
Ralf thinks [2] that one should not warn about this, and instead
only provide good documentation. But I don't think a documentation change
can address a pitfall like this, because it is so natural to use a
double-quoted program as first argument of AC_COMPILE_IFELSE. People
will not even think about this, will not realize that they need to look
up the documentation for such a seemingly simple macro use.
Can you do something about it?
Bruno
[1] http://lists.gnu.org/archive/html/bug-gnulib/2009-09/msg00042.html
[2] http://lists.gnu.org/archive/html/bug-gnulib/2010-07/msg00107.html
