pitfall with AC_*_IFELSE macros

[Bruno Haible]

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