AC_CHECK_HEADER won't use updates to CFLAGS/CPPFLAGS

[Rhys Ulerich]

Me again,

How many chickens must I sacrifice for AC_CHECK_HEADER to notice that I've
modified CFLAGS/CPPFLAGS within my configure script?

Within an m4 macro and using autoconf version 2.62:

    # Code to save LDFLAGS/CPPFLAGS/etc.
>
        LDFLAGS="-L${trilinos_libdir} $LDFLAGS"
>
    CPPFLAGS="-I${trilinos_include} $CPPFLAGS"
>     CFLAGS="-I${trilinos_include} $CFLAGS"
>
>     echo "DEBUG: $CFLAGS"
>     echo "DEBUG: $CPPFLAGS"
>
>
> AC_CHECK_HEADER([Trilinos_version.h],[found_header=yes],[found_header=no])


>
    #  Code to restore LDFLAGS/CPPFLAGS/etc if found_header=no
>
I see config.log behavior like

    configure:6196: checking Trilinos_version.h usability
>     configure:6213: g++ -c -g -O2  conftest.cpp >&5
>     conftest.cpp:51:30: error: Trilinos_version.h: No such file or
> directory
>
where neither my updated $CFLAGS nor my updated $CPPFLAGS appears in the g++
invocation.  That isn't what I expect based on
http://www.gnu.org/software/autoconf/manual/autoconf.html#Language-Choice.
A host of AC_LANG_PUSH and AC_LANG_ASSERT usage hasn't helped.  Neither has
me throwing CXXFLAGS or AC_CHECK_HEADERS (plural) into the mix.

Especially maddeningly, if I use 'CPPFLAGS=-Iquux ./configure' at the
command line -Iquux definitely shows up at configure:6213.

Any insight appreciated,
Rhys

P.S. Once this works I'll happily rip the CFLAGS part out.  I gather
CPPFLAGS is the right place to set -I options.