xc-cc-check.m4: re-evaluate exporting and AC_SUBST'ing vars
authorYang Tse <yangsita@gmail.com>
Mon, 21 Jan 2013 20:21:30 +0000 (21:21 +0100)
committerYang Tse <yangsita@gmail.com>
Mon, 21 Jan 2013 20:29:30 +0000 (21:29 +0100)
commitefe46566566d9d651f297041f39c057de588b329
tree9c696e239c039119cf00508f9453b6e2bd919f07
parent0ed4a0923c8ca0a3c1e20d9d99f80c63e92e8b81
xc-cc-check.m4: re-evaluate exporting and AC_SUBST'ing vars

Notes:

When running a configure script that has nested packages (for example
libcurl's configure with --enable-ares and c-ares sources embedded in
curl tree) and AC_CONFIG_SUBDIRS([nested-subdir]) machinery is used to
automatically run the nested configure script from within the parent
configure script, it happens that the nested _shell_ script will
inherit shell variables exported from the parent _shell_ script.

If for example parent configure script sets and exports LDFLAGS and LIBS
variables with proper values in order to link either a parent library or
program with a library which will be configured and built by a nested
package; It will happen that when the nested configure script runs, the
nested library does not exist yet and _any_ link-test done in the nested
configure will fail, such as those that autoconf macros perform in order
to detect existing compiler and its characteristics, the result is that
the nested configure script will fail with errors such as:

configure: error: C compiler cannot create executables

For now, we no longer export variables previously exported here.

On the other hand, AC_SUBST'ing them is appropriate and even with nested
packages each package's config.status gets its own package values.

So we reinstate AC_SUBST'ing previously AC_SUBST'ed variables.
m4/xc-cc-check.m4