Hello, Peter O'Gorman wrote: > include_next.m4 incorrectly deduces that this compiler understands > #include_next. The compiler issues a warning rather than an error when > it sees it. > > This should fix: > --- m4/include_next.m4~ 2007-07-18 03:21:47.089858027 +0000 > +++ m4/include_next.m4 2007-07-23 14:21:26.312399370 +0000 > @@ -11,9 +11,11 @@ > AC_LANG_PREPROC_REQUIRE() > AC_CACHE_CHECK([whether the preprocessor supports include_next], > [gl_cv_have_include_next], > - [AC_PREPROC_IFELSE([#include_next <stddef.h>], > + [save_werror_flag=$ac_c_werror_flag; ac_c_werror_flag=yes > + AC_PREPROC_IFELSE([#include_next <stddef.h>], > [gl_cv_have_include_next=yes], > - [gl_cv_have_include_next=no])]) > + [gl_cv_have_include_next=no]) > + ac_c_werror_flag=$save_werror_flag]) > if test $gl_cv_have_include_next = yes; then > > dnl FIXME: Remove HAVE_INCLUDE_NEXT and update everything that uses it
Thanks for the info. But relying on the presence or absence of stderr output of the compiler seems a bit risky to me. Can you rewrite the test so that it tests whether #include_next works for real? Something like this: mkdir confdir1 mkdir confdir2 echo ... > confdir1/conftest.h echo ... > confdir2/conftest.h save_CPPFLAGS="$CPPFLAGS" CPPFLAGS="$CPPFLAGS -Iconfdir1 -Iconfdir2" AC_PREPROC_IFELSE([#include <conftest.h>], ...) CPPFLAGS="$save_CPPFLAGS" ? This should be more robust. Bruno