Enrico Maria Crisostomo
2016-03-15 13:51:56 UTC
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,
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
Enrico M. Crisostomo