Modification of CXX and re-evaluation of dependent variables

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Modification of CXX and re-evaluation of dependent variables

Enrico Maria Crisostomo
Hi all,

I'm currently facing this issue: I'm using the AX_CXX_COMPILE_STDCXX_11
macro (which in turn uses AX_CXX_COMPILE_STDCXX) to check for C++11
compiler support.  If C++11 compiler support is detected, this macro
sets CXX by appending the relevant switch:

```
CXX="$CXX $switch"
```

So far, so good.  Problem is, other variables are evaluated in an
earlier stage from CXX, such as CXXCPP in AC_PROG_CXXCPP:

```
[...snip...]
if test -z "$CXXCPP"; then
   AC_CACHE_VAL(ac_cv_prog_CXXCPP,
   [dnl
 

     # Double quotes because CXXCPP needs to be expanded
 

     for CXXCPP in "$CXX -E" "/lib/cpp"
     do
       _AC_PROG_PREPROC_WORKS_IFELSE([break])
     done
     ac_cv_prog_CXXCPP=$CXXCPP
   ])dnl
 

   CXXCPP=$ac_cv_prog_CXXCPP
else
   ac_cv_prog_CXXCPP=$CXXCPP
fi
[...snip...]
```

After any macro such as AX_CXX_COMPILE_STDCXX_11 sets CXX, I found no
(clean) way to have Autoconf re-evaluate CXXCPP again (the check is
cached, and anyway calling AC_PROG_CXXCPP manually isn't transparent).

I think anybody that requests the compiler to be checked and configured
to support a certain C++ standard expects the preprocessor to be
configured as well.  I you don't, macros such AC_CHECK_HEADER wouldn't
detect correctly the configuration of the current build and emit warning
similar to these one:

```
checking atomic usability... yes
checking atomic presence... no
configure: WARNING: atomic: accepted by the compiler, rejected by the
preprocessor!
configure: WARNING: atomic: proceeding with the compiler's result
```

Which approach do you suggest to fix this problem?  Patching
AX_CXX_COMPILE_STDCXX_11 is possible, although it would create a
situation where the dependency between CXX and other variables is
tracked.  A very basic approach would be appending the same switch to
CXXCPP after setting CXX:

```
CXX="$CXX $switch"
# Warning: /lib/cpp is not being checked (as AC_PROG_CXXCPP does).
if test -n "$CXXCPP" ; then
   CXXCPP="$CXXCPP $switch"
fi
```

I'd rather invoke AC_PROG_CXXCPP in order not to duplicate code that
manages this kind of variable inter-dependency in multiple places as in:

```
CXX="$CXX $switch"
AC_PROG_CXXCPP
```

but that call it has no effect because the result is cached and not
re-evaluated.  Cleaning the variables used by AC_PROG_CXXCPP to force
re-evaluation is another hack, since you're again coupling a macro with
another one and in an even worse way (since you're relying on another
macro's internals)

Do you have any insights on this one?

Cheers,
--
Enrico M. Crisostomo


_______________________________________________
Autoconf mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/autoconf

smime.p7s (5K) Download Attachment
Loading...