[PATCH] {compilers-for-testsuite} readme: how to run the testsuite with cross-compilers

[Stefano Lattarini]

* tests/README: Suggest a better way to run the automake testsuite
with cross-compilers -- that is, configuring the Automake source
tree with proper `--build' and `--host' configure option.  And
yes, specifying both these options (not only `--host') is indeed
required to avoid spurious failures in corner cases.
When you call configure with the `--host' option but without the
`--build' option, configure tries to auto-detect whether you are
cross-compiling or not, by trying to run a generated executable.
That test might spuriously "succeed" in some corner cases (e.g.,
Cygwin is able to run non-Cygwin apps).  In fact, generally, it
can be the case that a cross-compilation is not detected as a
cross anymore just because someone has installed an emulator; as
an example, think of what can happen on a GNU/Linux system that
is configured (through the use of the binfmt_misc kernel module)
to execute PE executables (compiled for MS-DOS or Windows) through
Wine *automatically*.  In conclusion, configure needs to be used
as recommended in the documentation (i.e., by specifying *both*
`--host' and `--build' instead of just one of them) to not have
the build fall into any of a number of weird traps.
* tests/defs (cross_compiling): Improve comments.
---
 ChangeLog    |   25 +++++++++++++++++++++++++
 tests/README |   24 ++++++++++++------------
 tests/defs   |    7 +++++++
 3 files changed, 44 insertions(+), 12 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index bb741bb..05ef6b8 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,28 @@
+2011-12-20  Stefano Lattarini  <address@hidden>
+           Peter Rosin  <address@hidden>
+
+       readme: how to run the testsuite with cross-compilers
+       * tests/README: Suggest a better way to run the automake testsuite
+       with cross-compilers -- that is, configuring the Automake source
+       tree with proper `--build' and `--host' configure option.  And
+       yes, specifying both these options (not only `--host') is indeed
+       required to avoid spurious failures in corner cases.
+       When you call configure with the `--host' option but without the
+       `--build' option, configure tries to auto-detect whether you are
+       cross-compiling or not, by trying to run a generated executable.
+       That test might spuriously "succeed" in some corner cases (e.g.,
+       Cygwin is able to run non-Cygwin apps).  In fact, generally, it
+       can be the case that a cross-compilation is not detected as a
+       cross anymore just because someone has installed an emulator; as
+       an example, think of what can happen on a GNU/Linux system that
+       is configured (through the use of the binfmt_misc kernel module)
+       to execute PE executables (compiled for MS-DOS or Windows) through
+       Wine *automatically*.  In conclusion, configure needs to be used
+       as recommended in the documentation (i.e., by specifying *both*
+       `--host' and `--build' instead of just one of them) to not have
+       the build fall into any of a number of weird traps.
+       * tests/defs (cross_compiling): Improve comments.
+
 2011-10-25  Stefano Lattarini  <address@hidden>
 
        tests: no need to unset CFLAGS in tests requiring 'gcc' anymore
diff --git a/tests/README b/tests/README
index 980299d..4d7f21d 100644
--- a/tests/README
+++ b/tests/README
@@ -29,18 +29,18 @@ Running the tests
     make -k check TESTS="foo.test bar.test"             (GNU make)
     env TESTS="foo.test bar.test" make -e -k check      (non-GNU make)
 
- To run the tests in cross-compilation mode:
-
-    make -k check host_alias="$host_alias"              (GNU make)
-    env host_alias="$host_alias" make -e -k check       (non-GNU make)
-
- Here `$host_alias' should be defined to a proper value different from
- configure-determined `$build_alias', and should refer to a set of
- cross-compilers you have available on your system; for example, if
- on Linux you have a set of MinGW-targeted cross-compilers named
- 'i586-mingw32msvc-cc', 'i586-mingw32msvc-c++', etc., you could use:
-
-   make -k check host_alias='i586-mingw32msvc'
+ To run the tests in cross-compilation mode, you should first configure
+ the automake source tree to a cross-compilation setup.  For example, to
+ run with a Linux-to-Cygwin cross compiler, you will need something like
+ this:
+
+   ./configure --host i586-mingw32msvc --build i686-pc-linux-gnu
+
+ To avoid possible spurious error, you really have to *explicitly* specify
+ `--build' in addition to `--host'; the `lib/config.guess' script can help
+ you in determining what is the correct value you should pass to `--build'.
+ Then you can just run the testsuite in the usual way, and the test cases
+ using a compiler should automatically use a cross-compilation setup.
 
 
 Interpretation
diff --git a/tests/defs b/tests/defs
index 1a9ba37..ac2ebd4 100644
--- a/tests/defs
+++ b/tests/defs
@@ -228,6 +228,13 @@ diag_string_="#%#"
 # tests (or portions of them) that requires a native compiler.
 cross_compiling ()
 {
+  # Quoting from the autoconf manual:
+  #   ... [$host_alias and $build both] default to the result of running
+  #   config.guess, unless you specify either --build or --host.  In
+  #   this case, the default becomes the system type you specified.
+  #   If you specify both, *and they're different*, configure enters
+  #   cross compilation mode (so it doesn't run any tests that require
+  #   execution).
   test x"$host_alias" != x && test x"$build_alias" != x"$host_alias"
 }
 
-- 
1.7.2.3