autoconf
[Top][All Lists]
Advanced

[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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]