[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Modification of CXX and re-evaluation of dependent variables
From: |
Enrico Maria Crisostomo |
Subject: |
Modification of CXX and re-evaluation of dependent variables |
Date: |
Tue, 15 Mar 2016 14:51:56 +0100 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 |
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
smime.p7s
Description: S/MIME Cryptographic Signature
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Modification of CXX and re-evaluation of dependent variables,
Enrico Maria Crisostomo <=