[build] overriding configure test results

Message ID 20101002092916.GG13327@gmx.de
State New
Headers show

Commit Message

Ralf Wildenhues Oct. 2, 2010, 9:29 a.m.
Currently, toplevel configure passes on selected arguments to
subordinate configure scripts only.  There are cases where developers
may have a significantly easier time when they can pass arguments to sub
configures too.  Examples include broken configure tests or new ports
such as <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45326>
or cross-compilation setups triggering GCC_NO_EXECUTABLES just need to
be pre-seeded with some cache variable for Libtool macros, such as
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45174#c13>.  PR 38339 may
profit too, we're not done analyzing it yet though.

I'm guessing in 95% of those cases, it is sufficient to be able to
distinguish between build, host, and target configure scripts.  And
most of the time, passing CONFIG_SITE=... ought to be sufficient,
which doesn't need elaborate quoting for correct treatment.

The doc change was tested 'make pdf info html' and checking output
visually, the rest was tested with
  configure build_configargs='BBB=yes' host_configargs='HHH=yes' \

and checking the output of
  find $top_builddir -name config.log | xargs grep -l '^  \$.*BBB'

and similar for the other flags.  (The grepped line records the command
passed line arguments.)

The patch causes any settings of these variables to be recorded in
the 'Configured with:' line of 'gcc -v', even if they were set in the
environment rather than on the configure command line.

OK for trunk and sync to src (after getting GCC and src back into sync)?


Allow to pass separate configure arguments for build, host and target.

2010-10-02  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	PR bootstrap/45326
	PR bootstrap/45174
	* configure.ac: Honor initial values of $build_configargs,
	$host_configargs, $target_configargs.  Mark the precious, so
	environment settings get recorded.
	* configure: Regenerate.

2010-10-02  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* doc/install.texi (Configuration): Document build_configargs,
	host_configargs, target_configargs.


Paolo Bonzini Oct. 2, 2010, 2:04 p.m. | #1
On Sat, Oct 2, 2010 at 11:29, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> OK for trunk and sync to src (after getting GCC and src back into sync)?

Ok, thanks.



diff --git a/configure.ac b/configure.ac
index 6ef9df6..5f80aa9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2969,10 +2969,18 @@  if test "$silent" = yes; then
 baseargs="$baseargs --disable-option-checking"
+# Record and document user additions to sub configure arguments.
+	   [additional configure arguments for build directories])
+	   [additional configure arguments for host directories])
+	   [additional configure arguments for target directories])
 # For the build-side libraries, we just need to pretend we're native,
 # and not use the same cache file.  Multilibs are neither needed nor
 # desired.
-build_configargs="--cache-file=../config.cache ${baseargs}"
+build_configargs="$build_configargs --cache-file=../config.cache ${baseargs}"
 # For host modules, accept cache file option, or specification as blank.
 case "${cache_file}" in
@@ -2986,9 +2994,9 @@  esac
 # Host dirs don't like to share a cache file either, horribly enough.
 # This seems to be due to autoconf 2.5x stupidity.
-host_configargs="--cache-file=./config.cache ${extra_host_args} ${baseargs}"
+host_configargs="$host_configargs --cache-file=./config.cache ${extra_host_args} ${baseargs}"
+target_configargs="$target_configargs ${baseargs}"
 # Passing a --with-cross-host argument lets the target libraries know
 # whether they are being built with a cross-compiler or being built
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index a54b450..ce6b5cf 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -1991,6 +1991,36 @@  Do not try to compile and run a test libart program.
 @end table
+@subsubheading Overriding @command{configure} test results
+Sometimes, it might be necessary to override the result of some
+@command{configure} test, for example in order to ease porting to a new
+system or work around a bug in a test.  The toplevel @command{configure}
+script provides three variables for this:
+@table @code
+@item build_configargs
+@cindex @code{build_configargs}
+The contents of this variable is passed to all build @command{configure}
+@item host_configargs
+@cindex @code{host_configargs}
+The contents of this variable is passed to all host @command{configure}
+@item target_configargs
+@cindex @code{target_configargs}
+The contents of this variable is passed to all target @command{configure}
+@end table
+In order to avoid shell and @command{make} quoting issues for complex
+overrides, you can pass a setting for @env{CONFIG_SITE} and set
+variables in the site file.
 <hr />