[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Automake-commit] [SCM] GNU Automake branch, experimental/compilers-for-
From: |
Stefano Lattarini |
Subject: |
[Automake-commit] [SCM] GNU Automake branch, experimental/compilers-for-testsuite, created. v1.11-1604-gc59c61c |
Date: |
Tue, 20 Dec 2011 13:59:14 +0000 |
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU Automake".
http://git.sv.gnu.org/gitweb/?p=automake.git;a=commitdiff;h=c59c61ca4b0ba0659bd6ab058925ba97753221b6
The branch, experimental/compilers-for-testsuite has been created
at c59c61ca4b0ba0659bd6ab058925ba97753221b6 (commit)
- Log -----------------------------------------------------------------
commit c59c61ca4b0ba0659bd6ab058925ba97753221b6
Author: Stefano Lattarini <address@hidden>
Date: Tue Dec 20 11:33:36 2011 +0100
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.
commit 7bb652c617e9795132c93a874f9934ca014d1624
Author: Stefano Lattarini <address@hidden>
Date: Tue Oct 25 12:36:05 2011 +0200
tests: no need to unset CFLAGS in tests requiring 'gcc' anymore
* tests/ccnoco.test: Since this test have "gcc" in $required,
there is no need to manually nullify the CFLAGS variable, since
now `tests/defs' should automatically re-define that to a value
appropriate for gcc.
* tests/ccnoco3.test: Likewise.
commit ce8cd83de9c9c6ce42dc7c64174d96affb58f199
Author: Stefano Lattarini <address@hidden>
Date: Fri Oct 21 19:42:50 2011 +0200
test defs: allow compilers to be auto-selected on user's request
In the recent changes, by pre-setting the required compilers for
the `configure' scripts launched by the test scripts, we have
slightly reduced the coverage of autoconf/automake code aimed at
automatically detecting said compilers. This commit restore such
coverage, by allowing the user to instruct the testsuite *not* to
preset the testsuite compiler(s).
* tests/defs (cc): If $CC is set to the special value "autodetect"
or "autodetected", don't export the configure-detected CC, CFLAGS
and CPPFLAGS variables; rather, unset them.
(c++): Likewise, but for CXX, CFLAGS and CPPFLAGS instead.
(fortran): Likewise, but for FC and FCFLAGS instead.
(fortran77): Likewise, but for F77 and FFLAGS instead.
(require_compiler_): New function, to reduce code duplication.
commit 2109572b57be17db301992ef611f0fde2331350b
Author: Stefano Lattarini <address@hidden>
Date: Fri Oct 21 16:50:50 2011 +0200
test defs: substitute compilers and flags found at configure time
* tests/Makefile.am (do_subst): Also substitute CC, CXX, F77, FC,
CPPFLAGS, CFLAGS, CXXFLAGS, FCFLAGS and FFLAGS.
* tests/defs-static.in: Define those variables, allowing for
overrides from the environment.
* tests/defs (for tool in $required): Export (subsets of) those
variables when the stuff in `$required' calls for it.
Add related explanatory comments.
commit 010e011eafa317b22718badf7c86aa1fe75023bc
Author: Stefano Lattarini <address@hidden>
Date: Fri Sep 23 15:47:15 2011 +0200
test defs: setup `*FLAGS' variables for GNU compilers
* configure.ac: Setup some `*FLAGS' variables for use by the
GNU compilers in our testsuite. For example, use `GNU_CFLAGS'
instead of `CFLAGS', and so on for similar variables. This
is especially useful in case the compilers found or defined
at configure time are not the GNU ones.
* tests/defs-static.in: Initialize those same variables with
the values set at configure time, but allowing overrides
from the environment.
* tests/Makefile.am (do_subst): Process configure-style
substitutions of those variables (e.g., address@hidden@').
* tests/defs: When a GNU compiler is required, override the
corresponding generic `*FLAGS' variable with the GNU-specific
variant (e.g., redefine `$CFLAGS' to take the value of
`$GNU_CFLAGS').
commit 762f7d5699d2e7cc90cdc5a8f9ddfbf5a52a6bd0
Author: Stefano Lattarini <address@hidden>
Date: Fri Sep 23 00:00:22 2011 +0200
configure: search generic compilers for use in the tests
* configure.ac: Look for "generic" C, C++ and Fortran compilers,
with the aim of starting to use them in the testsuite (this will
be done in future changes). This is more tricky than it seems,
since we don't want to abort the whole configure script even if
no one of those compilers is available (after all, they're only
needed by the testsuite, not to build automake), but currently
autoconf doesn't offer an easy way to obtain this behaviour.
We prefer non-GNU compilers to the GNU ones, to ensure better
coverage "in the wild".
-----------------------------------------------------------------------
hooks/post-receive
--
GNU Automake
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Automake-commit] [SCM] GNU Automake branch, experimental/compilers-for-testsuite, created. v1.11-1604-gc59c61c,
Stefano Lattarini <=