Re: [PATCH v2 0/3] sysroot followup patches
Paolo, are you going to squash this:
http://lists.gnu.org/archive/html/libtool-patches/2010-08/msg00145.html
perhaps without this change:
- if $opt_dry_run; then
+ if ${opt_dry_run-false}; then
into
[PATCH] improve code for sysroot --mode=finish.eml
Yes of course.
Paolo
Re: [PATCH] Do not absolutize paths eagerly.
On 08/21/2010 08:03 AM, Ralf Wildenhues wrote: Fixed the regression as expected, didn't show up any other failures. OK to apply to the sysroot branch? I still need somebody to test a sysroot-enabled setup with this. I'm testing it now. Paolo
Re: [PATCH] Do not absolutize paths eagerly.
On 08/21/2010 08:03 AM, Ralf Wildenhues wrote: * Ralf Wildenhues wrote on Fri, Aug 20, 2010 at 06:34:58AM CEST: * libltdl/config/ltmain.m4sh (func_resolve_sysroot): Partly revert v2.2.10-83-gc45a288: Do not absolutize path here, only do sysroot replacement. (func_mode_link): Adjust. Fixes AIX testsuite regression. Maybe it's as simple as this? I'm testing this patch now. Would be nice if somebody could test it on a sysroot-enabled setup (i.e., where the sysroot tests don't skip). Fixed the regression as expected, didn't show up any other failures. OK to apply to the sysroot branch? I still need somebody to test a sysroot-enabled setup with this. It works, I pushed it. Paolo
Re: Tidy and fix clean and distclean rules for old testsuite.
Hi Gary, * Gary V. Vaughan wrote on Sun, Aug 22, 2010 at 06:46:55AM CEST: On 22 Aug 2010, at 11:23, Ralf Wildenhues wrote: OK to apply? Well, it is an improvement over what we have, so... sure, go ahead. Thanks for the quick review! However, I continue to strongly dislike the old testsuite, and would much prefer to migrate it's tests into Autotest. Oh. I was going to propose a patch series to convert the old testsuite to use the parallel-tests driver. Despite the new one having grown nicely, there are still several issues only found with the old one (and some tests in the new one that probably need more work). Oh well. I think I'll still propose the patch series, since it shouldn't make a future migration any worse. I don't intend to work on the migration myself; I prefer spending my time on other things. I understand the argument that our kludgy old tests are good for coverage of libtool with the bootstrapped autotools... but, honestly, I'd rather find out that the libtool I'm planning to install is going to fail with *my* autotools, than I would be told that the old testsuite still passes with whatever versions it happened to be bootstrapped with! Sure. Getting rid of the old testsuite was actually my motivation for starting an Autotest based testsuite in the first place; and because bootstrap and reconf issues with the old testsuite have always been (and continue to be) a real pain. And look what the new testsuite gained us: much better test coverage! In that way I think it's a huge success even if it hasn't (yet) achieved the goal you intended it for. :-) Cheers, Ralf
[PATCH 0/6] Allow to run the old testsuite in parallel
I've had this patch series half-done in my tree for a long time,
and have now taken the time to fix the missing bits.
The old testsuite is, well, old, and unloved. But it also covers
crucial aspects, so as long as there's no rewrite, we might as well
enable some parallelism and have a decent log creation mechanism (both
through Automake 1.11's parallel-tests feature).
Now, there are a few stumbling blocks: some tests depend upon prior
tests, some are run more than once, lots of them use the same trial
directories and files. Serialization can be achieved by adding
dependencies between tests and renaming/wrapping; parallel-tests runs
each test name at most once, given that it uses make rules to convert
tests to log files.
It would be possible to de-serialize for example the demo-static,
demo-conf, and demo-shared test groups by running them in different
build directories and installing them in different prefixes. In the
patch series, I chose (for now) not to go this route yet. We can still
go this way later. For now, this means that effectively, all the
demo-*.test tests are serialized.
Running a subset of the tests gets a little harder this way: since the
dependencies specify a total ordering, running, say, demo-shared.test
lets make think it requires running a bunch of others first. The GNU
make feature to specify order-only dependencies can alleviate that a
bit, and the patch series tries to exploit this when possible; if you're
not using 'make' for building, you would need to pass e.g., MAKE=gmake,
to configure to have this enabled.
Finally, the series improves the 'make check{non,}-interactive' rules
to also apply to the old testsuite as well, to hopefully benefit MSYS
and Cygwin Libtool developers.
I have tested the patch series (up to trivial changes) on several
systems, including MinGW, Cygwin, AIX, GNU/Linux, FreeBSD.
parallel-tests requires a new Automake for building the Libtool package
itself. Users of Libtool macros should still be able to cope with
Autoconf 2.59 and Automake 1.9.6. I tested this on GNU/Linux.
If requiring Automake 1.11.1 is too strict, then it would be possible,
alternatively, to only enable parallel-tests iff Automake is new enough.
This would make both code and documentation a bit more complicated, so
I'm hoping that it won't be necessary.
Feedback welcome. OK to merge?
Thanks,
Ralf
[PATCH 1/6] Require Automake 1.11.1 for Libtool, enable color-tests.
* configure.ac (AM_INIT_AUTOMAKE): Require 1.11.1. Enable
color-tests.
(LTDL_SUBDIR_LIBOBJS): Remove now-obsolete conditional and
feature test for Autoconf 2.59 and Automake 1.9.x workaround.
* Makefile.am: Simplify accordingly.
* bootstrap: Remove obsolete WORKING_LIBOBJ_SUPPORT workarounds
for Autoconf 2.59 and Automake 1.9.6.
Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de
---
ChangeLog| 11 +++
Makefile.am |9 -
bootstrap| 14 --
configure.ac | 10 ++
4 files changed, 13 insertions(+), 31 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 0d5840f..d17e7b5 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2010-08-22 Ralf Wildenhues ralf.wildenh...@gmx.de
+
+ Require Automake 1.11.1 for Libtool, enable color-tests.
+ * configure.ac (AM_INIT_AUTOMAKE): Require 1.11.1. Enable
+ color-tests.
+ (LTDL_SUBDIR_LIBOBJS): Remove now-obsolete conditional and
+ feature test for Autoconf 2.59 and Automake 1.9.x workaround.
+ * Makefile.am: Simplify accordingly.
+ * bootstrap: Remove obsolete WORKING_LIBOBJ_SUPPORT workarounds
+ for Autoconf 2.59 and Automake 1.9.6.
+
2010-08-21 Rainer Tammer tam...@tammer.net (tiny change)
Avoid issues with AIX resident shared libraries in old testsuite.
diff --git a/Makefile.am b/Makefile.am
index d689e09..78329d2 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -307,15 +307,6 @@ $(srcdir)/libltdl/config-h.in: $(sub_configure_deps)
include libltdl/Makefile.inc
-if ! LTDL_SUBDIR_LIBOBJS
-## workaround for Autoconf 2.59, Automake 1.9.6:
-## we include these files twice, because of missing LIBOBJDIR support.
-EXTRA_DIST += \
- argz.c libltdl/argz.c \
- lt__dirent.c libltdl/lt__dirent.c \
- lt__strl.c libltdl/lt__strl.c
-endif
-
## -- ##
## Documentation. ##
diff --git a/bootstrap b/bootstrap
index 410c983..7ad0979 100755
--- a/bootstrap
+++ b/bootstrap
@@ -46,7 +46,6 @@ export SHELL
: ${SED=sed}
: ${LN_S='ln -s'}
: ${MAKEINFO=makeinfo}
-: ${WORKING_LIBOBJ_SUPPORT=false}
case $1 in
--help|-h*)
@@ -54,8 +53,6 @@ case $1 in
`echo $0 | sed 's,^.*/,,g'`: This script is designed to bootstrap a fresh
repository checkout
of Libtool. Useful environment variable settings:
reconfdirs='. libltdl' Do not bootstrap the old test suite.
- WORKING_LIBOBJ_SUPPORT=: Declare that you have fixed LIBOBJDIR support
- in autoconf ( 2.59) and automake ( 1.9.6).
EOF
exit
;;
@@ -97,19 +94,8 @@ find . -depth \( -name autom4te.cache -o -name libtool \)
-print \
# Delete stale files from previous libtool versions.
rm -f acinclude.m4 libltdl/config.h
-# Workaround for missing LIBOBJDIR support in Autoconf 2.59, Automake 1.9.6:
-# Have symlinks of the libobj files in top source dir.
-# Set WORKING_LIBOBJ_SUPPORT=: when calling bootstrap if you have fixed tools.
-case `($AUTOCONF --version) 2/dev/null` in
- *\ 2.59[c-z]* | *\ 2.[6-9][0-9]* | *\ [3-9].[0-9]*)
- case `($AUTOMAKE --version) 2/dev/null` in
-*\ 1.9[a-z]* | *\ 1.1[0-9]* | *\ 1.[2-9][0-9]* | *\ [2-9].[0-9]*)
- WORKING_LIBOBJ_SUPPORT=: ;;
- esac ;;
-esac
for file in argz.c lt__dirent.c lt__strl.c; do
rm -f $file
- $WORKING_LIBOBJ_SUPPORT || $LN_S libltdl/$file $file
done
if test -z $reconfdirs; then
diff --git a/configure.ac b/configure.ac
index 35c79f1..e1d55ef 100644
--- a/configure.ac
+++ b/configure.ac
@@ -125,7 +125,8 @@ AC_SUBST([package_revision])
dnl These are bootstrap requirements! Once built, libtool may work with
dnl much older releases of autoconf and automake. See release notes.
-AM_INIT_AUTOMAKE([1.10.1 gnu subdir-objects dist-lzma])
+dnl 1.11 is needed for color-tests, 1.11.1 fixes a security issue.
+AM_INIT_AUTOMAKE([1.11.1 gnu subdir-objects dist-lzma color-tests])
dnl We use m4sh to generate libtool's portable shell scripts
AC_SUBST([M4SH], ['$(AUTOM4TE) --language=m4sh'])
@@ -133,13 +134,6 @@ AC_SUBST([M4SH], ['$(AUTOM4TE) --language=m4sh'])
dnl Make sure config.status is regenerated when the version timestamp changes
AC_SUBST([CONFIG_STATUS_DEPENDENCIES], ['$(top_srcdir)/ChangeLog'])
-dnl when installed libtool is used with automake-1.9.x or autoconf-2.59,
-dnl subdir libobjs don't work without a little extra help
-AC_MSG_CHECKING([whether subdir libobjs are useable])
-test -f $srcdir/argz.c || sublibobjs_supported=yes
-AM_CONDITIONAL([LTDL_SUBDIR_LIBOBJS], test x${sublibobjs_supported-no} !=
xno)
-AC_MSG_RESULT([${sublibobjs_supported-no}])
-
## --- ##
## Libtool specific configuration. ##
--
1.7.2.1.222.g9988
[PATCH 2/6] New alias scripts for old tests run more than once.
* tests/cdemo-shared-exec.test, tests/cdemo-shared-make.test, tests/cdemo-static-exec.test, tests/cdemo-static-make.test, tests/cdemo-undef-exec.test, tests/cdemo-undef-make.test, tests/demo-nofast-exec.test, tests/demo-nofast-inst.test, tests/demo-nofast-make.test, tests/demo-nofast-unst.test, tests/demo-nopic-exec.test, tests/demo-nopic-make.test, tests/demo-pic-exec.test, tests/demo-pic-make.test, tests/demo-shared-exec.test, tests/demo-shared-inst.test, tests/demo-shared-make.test, tests/demo-shared-unst.test, tests/demo-static-exec.test, tests/demo-static-inst.test, tests/demo-static-make.test, tests/demo-static-unst.test, tests/depdemo-nofast-exec.test, tests/depdemo-nofast-inst.test, tests/depdemo-nofast-make.test, tests/depdemo-nofast-unst.test, tests/depdemo-shared-exec.test, tests/depdemo-shared-inst.test, tests/depdemo-shared-make.test, tests/depdemo-shared-unst.test, tests/depdemo-static-exec.test, tests/depdemo-static-inst.test, tests/depdemo-static-make.test, tests/depdemo-static-unst.test, tests/f77demo-shared-exec.test, tests/f77demo-shared-make.test, tests/f77demo-static-exec.test, tests/f77demo-static-make.test, tests/fcdemo-shared-exec.test, tests/fcdemo-shared-make.test, tests/fcdemo-static-exec.test, tests/fcdemo-static-make.test, tests/mdemo-shared-exec.test, tests/mdemo-shared-inst.test, tests/mdemo-shared-make.test, tests/mdemo-shared-unst.test, tests/mdemo-static-exec.test, tests/mdemo-static-inst.test, tests/mdemo-static-make.test, tests/mdemo-static-unst.test, tests/tagdemo-shared-exec.test, tests/tagdemo-shared-make.test, tests/tagdemo-static-exec.test, tests/tagdemo-static-make.test, tests/tagdemo-undef-exec.test, tests/tagdemo-undef-make.test: New files. Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de --- The new tests currently depend on the fact that sourcing ./tests/defs is idempotent: it is read twice. This is a wee bit inefficient, but not really noticeable. If we care, we could set a flag so that the first time only $srcdir is computed. Thanks, Ralf ChangeLog | 31 +++ tests/cdemo-shared-exec.test |3 +++ tests/cdemo-shared-make.test |3 +++ tests/cdemo-static-exec.test |3 +++ tests/cdemo-static-make.test |3 +++ tests/cdemo-undef-exec.test|3 +++ tests/cdemo-undef-make.test|3 +++ tests/demo-nofast-exec.test|3 +++ tests/demo-nofast-inst.test|3 +++ tests/demo-nofast-make.test|3 +++ tests/demo-nofast-unst.test|3 +++ tests/demo-nopic-exec.test |3 +++ tests/demo-nopic-make.test |3 +++ tests/demo-pic-exec.test |3 +++ tests/demo-pic-make.test |3 +++ tests/demo-shared-exec.test|3 +++ tests/demo-shared-inst.test|3 +++ tests/demo-shared-make.test|3 +++ tests/demo-shared-unst.test|3 +++ tests/demo-static-exec.test|3 +++ tests/demo-static-inst.test|3 +++ tests/demo-static-make.test|3 +++ tests/demo-static-unst.test|3 +++ tests/depdemo-nofast-exec.test |3 +++ tests/depdemo-nofast-inst.test |3 +++ tests/depdemo-nofast-make.test |3 +++ tests/depdemo-nofast-unst.test |3 +++ tests/depdemo-shared-exec.test |3 +++ tests/depdemo-shared-inst.test |3 +++ tests/depdemo-shared-make.test |3 +++ tests/depdemo-shared-unst.test |3 +++ tests/depdemo-static-exec.test |3 +++ tests/depdemo-static-inst.test |3 +++ tests/depdemo-static-make.test |3 +++ tests/depdemo-static-unst.test |3 +++ tests/f77demo-shared-exec.test |3 +++ tests/f77demo-shared-make.test |3 +++ tests/f77demo-static-exec.test |3 +++ tests/f77demo-static-make.test |3 +++ tests/fcdemo-shared-exec.test |3 +++ tests/fcdemo-shared-make.test |3 +++ tests/fcdemo-static-exec.test |3 +++ tests/fcdemo-static-make.test |3 +++ tests/mdemo-shared-exec.test |3 +++ tests/mdemo-shared-inst.test |3 +++ tests/mdemo-shared-make.test |3 +++ tests/mdemo-shared-unst.test |3 +++ tests/mdemo-static-exec.test |3 +++ tests/mdemo-static-inst.test |3 +++ tests/mdemo-static-make.test |3 +++ tests/mdemo-static-unst.test |3 +++ tests/tagdemo-shared-exec.test |3 +++ tests/tagdemo-shared-make.test |3 +++ tests/tagdemo-static-exec.test |3 +++ tests/tagdemo-static-make.test |3 +++ tests/tagdemo-undef-exec.test |3 +++ tests/tagdemo-undef-make.test |3 +++ 57 files changed, 199 insertions(+), 0 deletions(-) create mode 100755 tests/cdemo-shared-exec.test create mode 100755 tests/cdemo-shared-make.test create mode 100755 tests/cdemo-static-exec.test create mode 100755 tests/cdemo-static-make.test create mode 100755 tests/cdemo-undef-exec.test create mode 100755 tests/cdemo-undef-make.test create mode 100755 tests/demo-nofast-exec.test create mode 100755 tests/demo-nofast-inst.test create mode 100755
[PATCH 6/6] check-interactive and check-noninteractive for both testsuites.
* Makefile.am (COMMON_TESTS, TESTS): Split into ... (NONINTERACTIVE_TESTS, INTERACTIVE_TESTS): ... these new variables. (check-interactive-new): Rename from check-interactive. (check-noninteractive-new): Rename from check-noninteractive. (check-interactive-old, check-noninteractive-old): New targets. (check-interactive, check-noninteractive): Depend on the respective targets for the old and the new test suites. * doc/libtool.texi (Test descriptions): Simplify description about check-interactive and check-noninteractive. Add index entries. * NEWS: Update. Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de --- ChangeLog| 13 + Makefile.am | 31 +++ NEWS |5 + doc/libtool.texi | 28 +++- 4 files changed, 48 insertions(+), 29 deletions(-) diff --git a/ChangeLog b/ChangeLog index e31a9d1..75b2298 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,18 @@ 2010-08-22 Ralf Wildenhues ralf.wildenh...@gmx.de + check-interactive and check-noninteractive for both testsuites. + * Makefile.am (COMMON_TESTS, TESTS): Split into ... + (NONINTERACTIVE_TESTS, INTERACTIVE_TESTS): ... these new + variables. + (check-interactive-new): Rename from check-interactive. + (check-noninteractive-new): Rename from check-noninteractive. + (check-interactive-old, check-noninteractive-old): New targets. + (check-interactive, check-noninteractive): Depend on the + respective targets for the old and the new test suites. + * doc/libtool.texi (Test descriptions): Simplify description + about check-interactive and check-noninteractive. Add index + entries. + Adjust docs for renaming and for parallel-tests. * README: Update example TESTS setting. * README.alpha: Likewise. diff --git a/Makefile.am b/Makefile.am index c507497..3df40fd 100644 --- a/Makefile.am +++ b/Makefile.am @@ -575,8 +575,13 @@ installcheck-local: $(testsuite_deps) $(TESTS_ENVIRONMENT) $(INSTALLCHECK_ENVIRONMENT) $(TESTSUITEFLAGS) \ AUTOTEST_PATH=$(exec_prefix)/bin +check-noninteractive-old: + $(MAKE) $(AM_MAKEFLAGS) check-TESTS TESTS='$(NONINTERACTIVE_TESTS)' +check-interactive-old: + $(MAKE) $(AM_MAKEFLAGS) check-TESTS TESTS='$(INTERACTIVE_TESTS)' + # Run only noninteractive parts of the new testsuite. -check-noninteractive: $(testsuite_deps_uninstalled) +check-noninteractive-new: $(testsuite_deps_uninstalled) $(CD_TESTDIR); \ CONFIG_SHELL=$(SHELL) $(SHELL) $$abs_srcdir/$(TESTSUITE) \ $(TESTS_ENVIRONMENT) $(BUILDCHECK_ENVIRONMENT) \ @@ -584,13 +589,16 @@ check-noninteractive: $(testsuite_deps_uninstalled) $(TESTSUITEFLAGS) # Run only interactive parts of the new testsuite. -check-interactive: $(testsuite_deps_uninstalled) +check-interactive-new: $(testsuite_deps_uninstalled) $(CD_TESTDIR); \ CONFIG_SHELL=$(SHELL) $(SHELL) $$abs_srcdir/$(TESTSUITE) \ $(TESTS_ENVIRONMENT) $(BUILDCHECK_ENVIRONMENT) \ -k interactive -k recursive INNER_TESTSUITEFLAGS=,interactive \ $(TESTSUITEFLAGS) +check-interactive: check-interactive-old check-interactive-new +check-noninteractive: check-noninteractive-old check-noninteractive-new + # We need to remove any file droppings left behind by testsuite clean-local: clean-local-legacy -$(CD_TESTDIR); \ @@ -753,7 +761,11 @@ COMMON_TESTS = \ tests/mdemo-shared-unst.test \ tests/cdemo-undef.test \ tests/cdemo-undef-make.test \ - tests/cdemo-undef-exec.test \ + tests/cdemo-undef-exec.test + +# Actually, only demo-relink and depdemo-relink require interaction, +# but they depend on the other tests being run beforehand. +INTERACTIVE_TESTS = \ tests/demo-shared.test \ tests/demo-shared-make.test \ tests/demo-shared-exec.test \ @@ -859,19 +871,22 @@ tests/pdemo-exec.log: tests/pdemo-make.log tests/pdemo-make.log: tests/pdemo-conf.log -TESTS = $(COMMON_TESTS) +NONINTERACTIVE_TESTS = $(COMMON_TESTS) if HAVE_CXX -TESTS += $(CXX_TESTS) +NONINTERACTIVE_TESTS += $(CXX_TESTS) endif if HAVE_F77 -TESTS += $(F77_TESTS) +# f77demo-static-exec.test might be interactive on MSYS. +INTERACTIVE_TESTS += $(F77_TESTS) endif if HAVE_FC -TESTS += $(FC_TESTS) +NONINTERACTIVE_TESTS += $(FC_TESTS) endif +TESTS = $(NONINTERACTIVE_TESTS) $(INTERACTIVE_TESTS) EXTRA_DIST += $(srcdir)/tests/defs.in tests/defs.m4sh \ - $(COMMON_TESTS) $(CXX_TESTS) $(F77_TESTS) $(FC_TESTS) + $(COMMON_TESTS) $(CXX_TESTS) $(F77_TESTS) $(FC_TESTS) \ + $(INTERACTIVE_TESTS) DIST_SUBDIRS += $(CONF_SUBDIRS) # The defs script shouldn't be recreated whenever the Makefile is diff --git a/NEWS b/NEWS index 9beb0f7..2357a8e 100644 --- a/NEWS +++ b/NEWS @@ -23,6 +23,11 @@ New in 2.2.12 2010-08-??: git version 2.2.11a, Libtool team:
[PATCH 3/6] Enable parallel-tests test driver for the old testsuite.
* configure.ac: New configure test to find out whether `make' supports order-only prerequisites; set @ORDER@ accordingly. (AM_INIT_AUTOMAKE): Enable parallel-tests option. * tests/defs.m4sh (prefix): Derive install prefix for tests from the test name, to avoid clashes. * Makefile.am (CXX_TESTS, F77_TESTS, FC_TESTS, COMMON_TESTS): Reformat. Adjust for renamed tests. Add dependencies between the respective log files of the tests, to ensure proper ordering. Use order-only dependencies if possible, between test groups that use the same directory. (clean-local-legacy): Remove `_inst-*' directories as well. Prompted by suggestion from Bob Friesenhahn. Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de --- ChangeLog | 14 +++ Makefile.am | 297 +-- configure.ac| 30 ++- tests/defs.m4sh |2 +- 4 files changed, 287 insertions(+), 56 deletions(-) diff --git a/ChangeLog b/ChangeLog index dcde33b..a1b2d07 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,19 @@ 2010-08-22 Ralf Wildenhues ralf.wildenh...@gmx.de + Enable parallel-tests test driver for the old testsuite. + * configure.ac: New configure test to find out whether `make' + supports order-only prerequisites; set @ORDER@ accordingly. + (AM_INIT_AUTOMAKE): Enable parallel-tests option. + * tests/defs.m4sh (prefix): Derive install prefix for tests + from the test name, to avoid clashes. + * Makefile.am (CXX_TESTS, F77_TESTS, FC_TESTS, COMMON_TESTS): + Reformat. Adjust for renamed tests. Add dependencies between + the respective log files of the tests, to ensure proper ordering. + Use order-only dependencies if possible, between test groups that + use the same directory. + (clean-local-legacy): Remove `_inst-*' directories as well. + Prompted by suggestion from Bob Friesenhahn. + New alias scripts for old tests run more than once. * tests/cdemo-shared-exec.test, tests/cdemo-shared-make.test, tests/cdemo-static-exec.test, tests/cdemo-static-make.test, diff --git a/Makefile.am b/Makefile.am index 78329d2..c507497 100644 --- a/Makefile.am +++ b/Makefile.am @@ -608,67 +608,256 @@ clean-local: clean-local-legacy # complete this section should be removed. CXX_TESTS = \ - tests/tagdemo-static.test tests/tagdemo-make.test \ - tests/tagdemo-exec.test tests/tagdemo-conf.test \ - tests/tagdemo-make.test tests/tagdemo-exec.test \ - tests/tagdemo-shared.test tests/tagdemo-make.test \ - tests/tagdemo-exec.test tests/tagdemo-undef.test \ - tests/tagdemo-make.test tests/tagdemo-exec.test + tests/tagdemo-static.test \ + tests/tagdemo-static-make.test \ + tests/tagdemo-static-exec.test \ + tests/tagdemo-conf.test \ + tests/tagdemo-make.test \ + tests/tagdemo-exec.test \ + tests/tagdemo-shared.test \ + tests/tagdemo-shared-make.test \ + tests/tagdemo-shared-exec.test \ + tests/tagdemo-undef.test \ + tests/tagdemo-undef-make.test \ + tests/tagdemo-undef-exec.test + +tests/tagdemo-undef-exec.log: tests/tagdemo-undef-make.log +tests/tagdemo-undef-make.log: tests/tagdemo-undef.log +tests/tagdemo-undef.log: tests/tagdemo-shared-exec.log +tests/tagdemo-shared-exec.log: tests/tagdemo-shared-make.log +tests/tagdemo-shared-make.log: tests/tagdemo-shared.log +tests/tagdemo-shared.log: tests/tagdemo-exec.log +tests/tagdemo-exec.log:tests/tagdemo-make.log +tests/tagdemo-make.log:tests/tagdemo-conf.log +tests/tagdemo-conf.log:tests/tagdemo-static-exec.log +tests/tagdemo-static-exec.log: tests/tagdemo-static-make.log +tests/tagdemo-static-make.log: tests/tagdemo-static.log F77_TESTS = \ - tests/f77demo-static.test tests/f77demo-make.test \ - tests/f77demo-exec.test tests/f77demo-conf.test \ - tests/f77demo-make.test tests/f77demo-exec.test \ - tests/f77demo-shared.test tests/f77demo-make.test \ - tests/f77demo-exec.test + tests/f77demo-static.test \ + tests/f77demo-static-make.test \ + tests/f77demo-static-exec.test \ + tests/f77demo-conf.test \ + tests/f77demo-make.test \ + tests/f77demo-exec.test \ + tests/f77demo-shared.test \ + tests/f77demo-shared-make.test \ + tests/f77demo-shared-exec.test + +tests/f77demo-shared-exec.log: tests/f77demo-shared-make.log +tests/f77demo-shared-make.log: tests/f77demo-shared.log +tests/f77demo-shared.log: tests/f77demo-exec.log +tests/f77demo-exec.log:tests/f77demo-make.log +tests/f77demo-make.log:tests/f77demo-conf.log +tests/f77demo-conf.log:tests/f77demo-static-exec.log +tests/f77demo-static-exec.log: tests/f77demo-static-make.log +tests/f77demo-static-make.log: tests/f77demo-static.log FC_TESTS = \ - tests/fcdemo-static.test
[PATCH 4/6] Update VERBOSE handling for parallel-tests driver.
* tests/defs.m4sh: Default to verbose output, drop now-unneeded
handling of 'VERBOSE=no'.
* README: Update example usage.
* README.alpha: Likewise.
* doc/libtool.texi (Test descriptions, When tests fail): Remove
unneeded VERBOSE recommendations. Point to per-test log files
and test-suite.log summary file.
Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de
---
ChangeLog|9 +
README | 14 +-
README.alpha | 14 +-
doc/libtool.texi | 14 +-
tests/defs.m4sh |9 ++---
5 files changed, 26 insertions(+), 34 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index a1b2d07..0363756 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,14 @@
2010-08-22 Ralf Wildenhues ralf.wildenh...@gmx.de
+ Update VERBOSE handling for parallel-tests driver.
+ * tests/defs.m4sh: Default to verbose output, drop now-unneeded
+ handling of 'VERBOSE=no'.
+ * README: Update example usage.
+ * README.alpha: Likewise.
+ * doc/libtool.texi (Test descriptions, When tests fail): Remove
+ unneeded VERBOSE recommendations. Point to per-test log files
+ and test-suite.log summary file.
+
Enable parallel-tests test driver for the old testsuite.
* configure.ac: New configure test to find out whether `make'
supports order-only prerequisites; set @ORDER@ accordingly.
diff --git a/README b/README
index 0a9317f..44396dc 100644
--- a/README
+++ b/README
@@ -76,15 +76,11 @@ If you wish to report a test group failure to the libtool
list, you need
to send the verbose output of the FAILing group, along with the
information from the end of `$(top_builddir)/libtool --help' to the bug
report mailing list, bug-libt...@gnu.org with a subject line that
-includes the string `[TEST FAILURE]'. From a Bourne compatible shell,
-you can generate verbose test output like this:
+includes the string `[TEST FAILURE]'. The file test-suite.log contains
+the verbose output from all failed tests.
- VERBOSE=yes gmake check \
- TESTS=tests/cdemo-static.test tests/cdemo-make.test tests/cdemo-exec.test \
- TESTSUITEFLAGS=-V | tee cdemo-static-group.log
-
-In order to enable debug shell tracing, use VERBOSE=debug instead of
-VERBOSE=yes.
+In order to enable debug shell tracing, you can set VERBOSE=debug when
+running the old test suite.
In the long run, Libtool will move to using only the new,
@@ -174,7 +170,7 @@ For more details about version numbers, see:
http://www.gnu.org/software/libtool/contribute.html
--
- Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009 Free Software
+ Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software
Foundation, Inc.
Written by Gary V. Vaughan, 2004
diff --git a/README.alpha b/README.alpha
index a785a7b..ca92329 100644
--- a/README.alpha
+++ b/README.alpha
@@ -81,15 +81,11 @@ If you wish to report a test group failure to the libtool
list, you need
to send the verbose output of the FAILing group, along with the
information from the end of `$(top_builddir)/libtool --help' to the bug
report mailing list, bug-libt...@gnu.org with a subject line that
-includes the string `[TEST FAILURE]'. From a Bourne compatible shell,
-you can generate verbose test output like this:
+includes the string `[TEST FAILURE]'. The file test-suite.log contains
+the verbose output from all failed tests.
- VERBOSE=yes gmake check \
- TESTS=tests/cdemo-static.test tests/cdemo-make.test tests/cdemo-exec.test \
- TESTSUITEFLAGS=-V | tee cdemo-static-group.log
-
-In order to enable debug shell tracing, use VERBOSE=debug instead of
-VERBOSE=yes.
+In order to enable debug shell tracing, you can set VERBOSE=debug when
+running the old test suite.
In the long run, Libtool will move to using only the new,
@@ -114,7 +110,7 @@ send the file `tests/testsuite.log' to the bug report
mailing list,
bug-libt...@gnu.org.
--
- Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009 Free Software
+ Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software
Foundation, Inc.
Written by Gary V. Vaughan, 2004
diff --git a/doc/libtool.texi b/doc/libtool.texi
index d0eaec4..bf51157 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -5121,8 +5121,8 @@ correspond to libtool's own notion of how your linker
behaves.
@pindex demo-relink.test
@pindex depdemo-relink.test
These tests check whether variable @code{shlibpath_overrides_runpath} is
-properly set. If the test fails and @env{VERBOSE} is set, it will
-indicate what the variable should have been set to.
+properly set. If the test fails, it will indicate what the variable should
+have been set to.
@item demo-noinst-link.test
@pindex demo-noinst-link.test
@@ -5396,8 +5396,9 @@ test suite.
@cindex failed tests
@cindex tests, failed
-Each of the tests in the old test suite are designed to produce no
-output when they are run via @kbd{make check}. The exit status of each
+When the tests in the
[PATCH 5/6] Adjust docs for renaming and for parallel-tests.
* README: Update example TESTS setting.
* README.alpha: Likewise.
* NEWS: Update.
* doc/libtool.texi (Test descriptions): Update for test renaming,
adjust descriptions accordingly.
Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de
---
ChangeLog|6 ++
NEWS | 10 +++
README |4 +-
README.alpha |4 +-
doc/libtool.texi | 162 +
5 files changed, 157 insertions(+), 29 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 0363756..e31a9d1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
2010-08-22 Ralf Wildenhues ralf.wildenh...@gmx.de
+ Adjust docs for renaming and for parallel-tests.
+ * README: Update example TESTS setting.
+ * README.alpha: Likewise.
+ * doc/libtool.texi (Test descriptions): Update for test renaming,
+ adjust descriptions accordingly.
+
Update VERBOSE handling for parallel-tests driver.
* tests/defs.m4sh: Default to verbose output, drop now-unneeded
handling of 'VERBOSE=no'.
diff --git a/NEWS b/NEWS
index 95fa97d..9beb0f7 100644
--- a/NEWS
+++ b/NEWS
@@ -6,8 +6,18 @@ New in 2.2.12 2010-08-??: git version 2.2.11a, Libtool team:
- On non-cygwin Windows systems, we now lookup potential library
file names without regard to file name case.
+ - The old testsuite now uses the `parallel-tests' Automake test driver
+now for more concurrency and better test logging. For this, tests are
+run in verbose mode by default now.
+
+* Important incompatible changes:
+
+ - Autoconf 2.62 and Automake 1.11.1 or newer are now required for building
+Libtool. For using Libtool in your own projects, Autoconf 2.59 and
+Automake 1.9.6 should still work.
* Changes in supported systems or compilers:
+
- Initial support for the Microsoft C/C++ Compiler, with help from
the compile script in unreleased Automake 1.12. Override the manifest
tool used to embed the manifest resource through the environment
diff --git a/README b/README
index 44396dc..0c13518 100644
--- a/README
+++ b/README
@@ -64,8 +64,8 @@ To run a test group of the old test suite in isolation (say,
you think
you have fixed a bug, but don't want to rerun the entire suite), you can
do it like this:
- gmake check TESTS=tests/cdemo-static.test tests/cdemo-make.test \
- tests/cdemo-exec.test \
+ gmake check TESTS=tests/cdemo-static.test tests/cdemo-static-make.test \
+ tests/cdemo-static-exec.test \
TESTSUITEFLAGS=-V
Providing that you have a FAIL from the most recent group from a
diff --git a/README.alpha b/README.alpha
index ca92329..2632e75 100644
--- a/README.alpha
+++ b/README.alpha
@@ -69,8 +69,8 @@ To run a test group of the old test suite in isolation (say,
you think
you have fixed a bug, but don't want to rerun the entire suite), you can
do it like this:
- gmake check TESTS=tests/cdemo-static.test tests/cdemo-make.test \
- tests/cdemo-exec.test \
+ gmake check TESTS=tests/cdemo-static.test tests/cdemo-static-make.test \
+ tests/cdemo-static-exec.test \
TESTSUITEFLAGS=-V
Providing that you have a FAIL from the most recent group from a
diff --git a/doc/libtool.texi b/doc/libtool.texi
index bf51157..26f9d9e 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -5032,17 +5032,29 @@ they test for:
@table @file
@item cdemo-conf.test
-...@itemx cdemo-exec.test
@itemx cdemo-make.test
+...@itemx cdemo-exec.test
@itemx cdemo-static.test
+...@itemx cdemo-static-make.test
+...@itemx cdemo-static-exec.test
@itemx cdemo-shared.test
+...@itemx cdemo-shared-make.test
+...@itemx cdemo-shared-exec.test
@itemx cdemo-undef.test
+...@itemx cdemo-undef-make.test
+...@itemx cdemo-undef-exec.test
@pindex cdemo-conf.test
-...@pindex cdemo-exec.test
@pindex cdemo-make.test
+...@pindex cdemo-exec.test
@pindex cdemo-static.test
+...@pindex cdemo-static-make.test
+...@pindex cdemo-static-exec.test
@pindex cdemo-shared.test
+...@pindex cdemo-shared-make.test
+...@pindex cdemo-shared-exec.test
@pindex cdemo-undef.test
+...@pindex cdemo-undef-make.test
+...@pindex cdemo-undef-exec.test
These programs check to see that the @file{tests/cdemo} subdirectory of
the libtool distribution can be configured and built correctly.
@@ -5051,8 +5063,8 @@ convenience libraries, a mechanism that allows build-time
static
libraries to be created, in a way that their components can be later
linked into programs or other libraries, even shared ones.
-The tests @file{cdemo-make.test} and @file{cdemo-exec.test} are executed
-three times, under three different libtool configurations:
+The tests matching @file{cdemo-*make.test} and @file{cdemo-*exec.test}
+are executed three times, under three different libtool configurations:
@file{cdemo-conf.test} configures @file{cdemo/libtool} to build both
static and shared libraries (the default for
Re: Tidy and fix clean and distclean rules for old testsuite.
Hallo Ralf, On 22 Aug 2010, at 17:29, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Sun, Aug 22, 2010 at 06:46:55AM CEST: On 22 Aug 2010, at 11:23, Ralf Wildenhues wrote: However, I continue to strongly dislike the old testsuite, and would much prefer to migrate it's tests into Autotest. Oh. I was going to propose a patch series to convert the old testsuite to use the parallel-tests driver. Despite the new one having grown nicely, there are still several issues only found with the old one (and some tests in the new one that probably need more work). Oh well. I think I'll still propose the patch series, since it shouldn't make a future migration any worse. I don't intend to work on the migration myself; I prefer spending my time on other things. Sure, a step forward is a step forward. And besides I might not find the time to work on migrating the old tests for a long while, and have a less annoying old testsuite is definitely a good thing in my book :) I understand the argument that our kludgy old tests are good for coverage of libtool with the bootstrapped autotools... but, honestly, I'd rather find out that the libtool I'm planning to install is going to fail with *my* autotools, than I would be told that the old testsuite still passes with whatever versions it happened to be bootstrapped with! Sure. Getting rid of the old testsuite was actually my motivation for starting an Autotest based testsuite in the first place; and because bootstrap and reconf issues with the old testsuite have always been (and continue to be) a real pain. And look what the new testsuite gained us: much better test coverage! Yes indeed! In that way I think it's a huge success even if it hasn't (yet) achieved the goal you intended it for. :-) That's great. I could have sworn that we discussed this and reached a consensus that the old tests should stay... but a quick search through the archives didn't turn up the conversation I thought I'd remembered. I would have done the work to migrate long ago if my memory hadn't been implanted by aliens (8 I've added it to my TODO, so it should arrive here at some point in the not too distant future. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH 0/6] Allow to run the old testsuite in parallel
Hallo Ralf, On 22 Aug 2010, at 17:55, Ralf Wildenhues wrote: I've had this patch series half-done in my tree for a long time, and have now taken the time to fix the missing bits. Do you have (or could you easily move) this on a private topic branch already? If so, please push the topic branch to a public repo to make it easier for me to test. The old testsuite is, well, old, and unloved. But it also covers crucial aspects, so as long as there's no rewrite, we might as well enable some parallelism and have a decent log creation mechanism (both through Automake 1.11's parallel-tests feature). Sounds good. As do the benefits to Windows testers that I elided from the quoted text. I'd still like to roll the next release in a week or two though. Do you think this patch series is stable enough to push just before that release? I'm leaning towards holding off until just after the release: anyone who wants to test that code can easily clone the post-release head of the master branch... and we don't run the risk of making a release that blows up for casual users in unforseen ways. WDYT? parallel-tests requires a new Automake for building the Libtool package itself. Users of Libtool macros should still be able to cope with Autoconf 2.59 and Automake 1.9.6. I tested this on GNU/Linux. So, with a distribution's preinstalled libtool package, we are still able to work fully with older autotools, and the Automake 1.11.1 requirement is only for running the old testsuite? Or only for running the old testsuite in parallel? If requiring Automake 1.11.1 is too strict, then it would be possible, alternatively, to only enable parallel-tests iff Automake is new enough. This would make both code and documentation a bit more complicated, so I'm hoping that it won't be necessary. I'd like to try it out (preferably without extracting the patches from emails on my laptop, transferring them to the test servers, and applying them there) before giving the all clear. But, I think it is not worth your expending too much more effort on enhancing this series if my plan to migrate those tests to Autotest comes to fruition in the next month or two, so if I don't get back with a review in 72hrs, and if you are confident that we're not opening ourselves up to a slew of reports from casual early adopters who have trouble with the altered testsuite, then in principle I have no problem with merging. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH 1/6] Require Automake 1.11.1 for Libtool, enable color-tests.
Hallo Ralf, On 22 Aug 2010, at 17:56, Ralf Wildenhues wrote: (LTDL_SUBDIR_LIBOBJS): Remove now-obsolete conditional and feature test for Autoconf 2.59 and Automake 1.9.x workaround. * Makefile.am: Simplify accordingly. * bootstrap: Remove obsolete WORKING_LIBOBJ_SUPPORT workarounds for Autoconf 2.59 and Automake 1.9.6. Earlier comments aside, I'm very happy to throw away a requirement for 7 and 5 year old Autoconf and Automake (resp) under any circumstances. So this part is good with me already! * configure.ac (AM_INIT_AUTOMAKE): Require 1.11.1. Enable color-tests. I'm still a little worried that the Automake 1.11.1 requirement might leak out of 'required to bootstrap' and into 'required to use' however, which is why I'd like to test it some more to convince myself that I'm just being paranoid :) I wonder whether it is possible to write a test that looks for the oldest Automake and Autoconf we declare our support for, and rerun the relevant tests with them? That would have caught several of the errors I made with the m4sh patches I submitted over the last couple of months... Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH 0/6] Allow to run the old testsuite in parallel
Hi Gary, * Gary V. Vaughan wrote on Sun, Aug 22, 2010 at 04:05:12PM CEST: On 22 Aug 2010, at 17:55, Ralf Wildenhues wrote: I've had this patch series half-done in my tree for a long time, and have now taken the time to fix the missing bits. Do you have (or could you easily move) this on a private topic branch already? If so, please push the topic branch to a public repo to make it easier for me to test. Done now: it's named parallel-tests. I'd still like to roll the next release in a week or two though. Do you think this patch series is stable enough to push just before that release? I was definitely aiming for this release. Actually, I have one more patch to use Autobuild, and my plan was to then get the sysroot branch merged and then build and test Libtool in all setups I have available and send them to the Autobuild site for reference. This parallel-tests patch series makes it easier to submit logs of the failed tests. I'm leaning towards holding off until just after the release: anyone who wants to test that code can easily clone the post-release head of the master branch... and we don't run the risk of making a release that blows up for casual users in unforseen ways. WDYT? Well, I hope that I can convince you otherwise, but sure, after the release is still better than never. Maybe it helps to explain that I actually had the meat of this patch, the parallel-tests enabling code, in my test tree for almost two years now. In fact, when I merged Akim's parallel-tests driver code, I used Libtool as testing ground. So, while obviously there can be bugs, and due to size alone chances are there will be ;-) I'm optimistic that this won't be too risky. parallel-tests requires a new Automake for building the Libtool package itself. Users of Libtool macros should still be able to cope with Autoconf 2.59 and Automake 1.9.6. I tested this on GNU/Linux. So, with a distribution's preinstalled libtool package, we are still able to work fully with older autotools, and the Automake 1.11.1 requirement is only for running the old testsuite? Or only for running the old testsuite in parallel? The new Automake is merely needed for the toplevel Makefile. It is not needed for the old tests/demo*/ directories and not for running any of the tests. Autoconf 2.62 is purely needed for the toplevel configure and for creating scripts that use getopt.m4sh. I verified each of these two requirements, by running autoreconf-2.59 in all old tests/demo*/ directories, having Autoconf 2.59 and Automake 1.9.6 first in $PATH, and running 'make -k check' that way, successfully, on GNU/Linux. I'd like to try it out (preferably without extracting the patches from emails on my laptop, transferring them to the test servers, and applying them there) before giving the all clear. Of course. But, I think it is not worth your expending too much more effort on enhancing this series if my plan to migrate those tests to Autotest comes to fruition in the next month or two, so if I don't get back with a review in 72hrs, and if you are confident that we're not opening ourselves up to a slew of reports from casual early adopters who have trouble with the altered testsuite, then in principle I have no problem with merging. Great. Thanks! Ralf
Re: [PATCH 5/6] Adjust docs for renaming and for parallel-tests.
* Ralf Wildenhues wrote on Sun, Aug 22, 2010 at 12:57:31PM CEST: * README: Update example TESTS setting. * README.alpha: Likewise. * NEWS: Update. * doc/libtool.texi (Test descriptions): Update for test renaming, adjust descriptions accordingly. --- a/NEWS +++ b/NEWS +* Important incompatible changes: + + - Autoconf 2.62 and Automake 1.11.1 or newer are now required for building +Libtool. For using Libtool in your own projects, Autoconf 2.59 and +Automake 1.9.6 should still work. That should be s/building/bootstrapping/ because for building from a release tarball, the new versions are not required. I'll add a bugfix patch to the branch before an eventual merge. Thanks, Ralf
Re: [PATCH 1/6] Require Automake 1.11.1 for Libtool, enable color-tests.
* Gary V. Vaughan wrote on Sun, Aug 22, 2010 at 04:17:49PM CEST: I'm still a little worried that the Automake 1.11.1 requirement might leak out of 'required to bootstrap' and into 'required to use' however, which is why I'd like to test it some more to convince myself that I'm just being paranoid :) I wonder whether it is possible to write a test that looks for the oldest Automake and Autoconf we declare our support for, and rerun the relevant tests with them? That would have caught several of the errors I made with the m4sh patches I submitted over the last couple of months... Ah, maybe a good idea. Assuming you have new enough tools in $PATH, a script like the following should almost do it. One missing part I can see is that the second invocation of ./boostrap in the libtool source tree messes up libltdl/config/ltmain.sh which it shouldn't do if '.' is not in $reconfdirs I think. Haven't tested exhaustively yet, though. Cheers, Ralf --- snip --- #! /bin/sh # Try out Libtool with oldest supported tools. # Use this in a fresh directory. set -e # consider using shallow clones here, to ease server load. git clone git://git.sv.gnu.org/autoconf.git git clone git://git.sv.gnu.org/automake.git git clone git://git.sv.gnu.org/libtool.git mkdir inst inst=`pwd`/inst PATH=$inst/bin:$PATH cd libtool reconfdirs=. ./bootstrap cd ../autoconf git checkout AUTOCONF-2.59 # autoreconf -vi needed here? ./configure --prefix=$inst make all install cd ../automake git checkout Release-1-9-6 ./bootstrap ./configure --prefix=$inst make all install cd ../libtool reconfdirs=libltdl `ls -d tests/*demo*/` ./bootstrap mkdir build cd build ../configure --prefix=$inst make all make -k check # Now, mail all output and logs to the autobuild site ... # ... and consider cleaning up afterwards.
Re: using git Libtool with Autoconf 2.59, Automake 1.9.6
* Gary V. Vaughan wrote on Sat, Aug 21, 2010 at 12:27:12PM CEST: On 21 Aug 2010, at 12:06, Ralf Wildenhues wrote: I tried running the Libtool test suites with old Autoconf 2.59 and Automake 1.9.6 (on GNU/Linux only) after 'autoreconf -fvi'-ing all but the toplevel directory with those tools. I was surprised to see that it still works more or less! :-) This patch fixes the fall-out. OK to push if the use of $at_status is sanctioned? http://thread.gmane.org/gmane.comp.sysutils.autoconf.patches/7323 Nice catch! I have no idea about at_status, but pending that please do push. Pushed now, under the provisional OK from Paul on autoconf-patches. (If Autoconf does change later, then we're still not worse off than we were before the patch, because at_status is only examined in the failure case anyway.) Thanks for the speedy review! Ralf
Re: [PATCH 1/6] Require Automake 1.11.1 for Libtool, enable color-tests.
Hallo Ralf, On 22 Aug 2010, at 22:09, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Sun, Aug 22, 2010 at 04:17:49PM CEST: I wonder whether it is possible to write a test that looks for the oldest Automake and Autoconf we declare our support for, and rerun the relevant tests with them? That would have caught several of the errors I made with the m4sh patches I submitted over the last couple of months... Ah, maybe a good idea. [[snip]] Thanks :) #! /bin/sh # Try out Libtool with oldest supported tools. # Use this in a fresh directory. set -e # consider using shallow clones here, to ease server load. git clone git://git.sv.gnu.org/autoconf.git git clone git://git.sv.gnu.org/automake.git We could pull the already bootstrapped release tarballs from an ftp.gnu.org mirror here instead. git clone git://git.sv.gnu.org/libtool.git Of course, that doesn't test the patch series you haven't pushed yet... And running it as an Autotest inside the existing tree would get us better coverage, and obviate the need for a separate checkout of the libtool tree entirely. mkdir inst inst=`pwd`/inst PATH=$inst/bin:$PATH cd libtool reconfdirs=. ./bootstrap cd ../autoconf git checkout AUTOCONF-2.59 # autoreconf -vi needed here? ./configure --prefix=$inst make all install cd ../automake git checkout Release-1-9-6 ./bootstrap ./configure --prefix=$inst make all install cd ../libtool reconfdirs=libltdl `ls -d tests/*demo*/` ./bootstrap mkdir build cd build ../configure --prefix=$inst make all make -k check # Now, mail all output and logs to the autobuild site ... # ... and consider cleaning up afterwards. The last bit of the script is missing ;) Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH v2 0/3] sysroot followup patches
Hello Paolo, Charles, I think these are the leftover items, right? * Paolo Bonzini wrote on Fri, Aug 13, 2010 at 03:23:02AM CEST: 4) patch for old libtool, to not barf on '=' 6) support in libltdl for '=' in .la files 7) doc updates. I think the sysroot branch is in pretty good shape and all remaining items can be argued to not be regressions. Thus, it might be a good idea to merge the branch to master now so that we can easily test it all together. So, barring disagreement from any of the other maintainers within the next 72 hours, let's merge the current sysroot branch. Of course, we should still aim to complete as much as possible before the release. I didn't do 4 because I noticed Fedora-mingw32's build system is running libtoolize on all packages, because of the much improved libtool support for Mingw32 in recent libtools. It would still be useful for other cross-compilation scenarios than mingw. I would like some help for 6 mostly due to lack of time on my part. The main design point here is how to pass the sysroot to libltdl. For me, that will definitely have to wait 'till next weekend, sorry. The series also includes a testsuite update so that it works on Fedora 13 (using the mingw cross-compilation environment) and testsuite coverage for the --mode=finish changes. That's good! Cheers, Ralf
Re: [PATCH 0/6] Allow to run the old testsuite in parallel
On 22 Aug 2010, at 21:30, Ralf Wildenhues wrote: Hi Gary, Hallo Ralf! * Gary V. Vaughan wrote on Sun, Aug 22, 2010 at 04:05:12PM CEST: On 22 Aug 2010, at 17:55, Ralf Wildenhues wrote: I've had this patch series half-done in my tree for a long time, and have now taken the time to fix the missing bits. Do you have (or could you easily move) this on a private topic branch already? If so, please push the topic branch to a public repo to make it easier for me to test. Done now: it's named parallel-tests. That's great. Thanks :) I'm pulling the branch now... although it will be Monday here in just over an hour, so I'll probably get some sleep before I look at it properly. I'd still like to roll the next release in a week or two though. Do you think this patch series is stable enough to push just before that release? I was definitely aiming for this release. Actually, I have one more patch to use Autobuild, and my plan was to then get the sysroot branch merged and then build and test Libtool in all setups I have available and send them to the Autobuild site for reference. This parallel-tests patch series makes it easier to submit logs of the failed tests. Okay, I'm convinced (pending the results of my testing); that's a lot of advantages for a comparatively small risk. I'd like to do at least one more release after the next one before the end of the year anyway, so we have the opportunity to address anything unexpected that does come up. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH 1/6] Require Automake 1.11.1 for Libtool, enable color-tests.
* Gary V. Vaughan wrote on Sun, Aug 22, 2010 at 05:24:05PM CEST: On 22 Aug 2010, at 22:09, Ralf Wildenhues wrote: # consider using shallow clones here, to ease server load. git clone git://git.sv.gnu.org/autoconf.git git clone git://git.sv.gnu.org/automake.git We could pull the already bootstrapped release tarballs from an ftp.gnu.org mirror here instead. Sure. git clone git://git.sv.gnu.org/libtool.git Of course, that doesn't test the patch series you haven't pushed yet... Just add 'git checkout origin/parallel-tests'. And running it as an Autotest inside the existing tree would get us better coverage, and obviate the need for a separate checkout of the libtool tree entirely. Sure. But look at the existing sort-of-recursive tests. They are tricky. I am waiting for the day where we add infinite recursion in some corner case and have developers complain. The net is abundant now, I think such test helper scripts are a real easy way to get more coverage, but I don't think it is necessary to run them as part of each testsuite run, because they are very expensive. # Now, mail all output and logs to the autobuild site ... # ... and consider cleaning up afterwards. The last bit of the script is missing ;) TBD when I have all the autobuild setup figured out and all. Cheers, Ralf
Re: [PATCH 1/6] Require Automake 1.11.1 for Libtool, enable color-tests.
On 22 Aug 2010, at 22:30, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Sun, Aug 22, 2010 at 05:24:05PM CEST: On 22 Aug 2010, at 22:09, Ralf Wildenhues wrote: # consider using shallow clones here, to ease server load. git clone git://git.sv.gnu.org/autoconf.git git clone git://git.sv.gnu.org/automake.git We could pull the already bootstrapped release tarballs from an ftp.gnu.org mirror here instead. Sure. git clone git://git.sv.gnu.org/libtool.git Of course, that doesn't test the patch series you haven't pushed yet... Just add 'git checkout origin/parallel-tests'. I meant that if I want to check that my next round of m4sh patches don't break with older Autotools before I push, this script doesn't help, since it wants a fresh libtool checkout. The script would be more useful if it can be run inside a dirty working directory. And running it as an Autotest inside the existing tree would get us better coverage, and obviate the need for a separate checkout of the libtool tree entirely. Sure. But look at the existing sort-of-recursive tests. They are tricky. I am waiting for the day where we add infinite recursion in some corner case and have developers complain. Actually, I've not looked at the details of those recursive tests, so I must admit that I don't know how tricky they are. I just assumed that we could reuse that pattern here. The net is abundant now, I think such test helper scripts are a real easy way to get more coverage, but I don't think it is necessary to run them as part of each testsuite run, because they are very expensive. A very good point. Maybe we should add a 'maintainer-test' target or similar, which executes this and other expensive test-helper scripts in addition to the regular testsuite(s). And it's also worth considering migrating our other recursive tests to helper scripts too in that case. # Now, mail all output and logs to the autobuild site ... # ... and consider cleaning up afterwards. The last bit of the script is missing ;) TBD when I have all the autobuild setup figured out and all. Kidding!! LOL Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH v2 0/3] sysroot followup patches
On 8/22/2010 11:26 AM, Ralf Wildenhues wrote: Hello Paolo, Charles, I think these are the leftover items, right? * Paolo Bonzini wrote on Fri, Aug 13, 2010 at 03:23:02AM CEST: 4) patch for old libtool, to not barf on '=' 6) support in libltdl for '=' in .la files 7) doc updates. Yes, that is the entire remaining list IIRC. I think the sysroot branch is in pretty good shape and all remaining items can be argued to not be regressions. Thus, it might be a good idea to merge the branch to master now so that we can easily test it all together. So, barring disagreement from any of the other maintainers within the next 72 hours, let's merge the current sysroot branch. I agree. Of course, we should still aim to complete as much as possible before the release. Of course (especially docs). I would like some help for 6 mostly due to lack of time on my part. The main design point here is how to pass the sysroot to libltdl. For me, that will definitely have to wait 'till next weekend, sorry. Ack. Given the tentative plan to roll out a libtool-2.2.next by the end of this month (august) with some msvc support -- and Peter's statement that some of his remaining msvc patches require my cross-path support patch, I'm going to roll that out (against master, not sysroot) later today, in preference to working on the libltdl patches. I've tested the cross-path patch (in the past) in the following configurations: cygwin (native) mingw (native; e.g. msys in its normal pretend I am mingw32 personality) linux (native) linux-mingw cross (*) I plan to repeat ALL of those tests, plus cygwin-mingw cross linux-cygwin cross (*) (**) msys-msys (native; e.g. msys in its okay, I'm actually a cygwin-like unix environment personality) (*) as with all cross configurations, the -exec tests are skipped as part of the official test run. However, I'll spot check by manually checking the contents of the c wrapper source code, and manually running the executable from the builddir. (**) I need to actually compile and install these tools on my linux box; so far there are no public linux-cygwin cross tool chains available out there for immediate use. Anyway, this test series will take DAYS to complete...so I'd appreciate it if the review (or, the reviewER's refresh/reread of the OLD reviews, whose links I will post) could commence concurrent with my generation of the test results. I don't expect any surprise in those test results, tho... -- Chuck
Re: [PATCH v2 0/3] sysroot followup patches
Hi Charles, I agree with all you wrote. * Charles Wilson wrote on Sun, Aug 22, 2010 at 08:05:33PM CEST: Anyway, this test series will take DAYS to complete...so I'd appreciate it if the review (or, the reviewER's refresh/reread of the OLD reviews, whose links I will post) could commence concurrent with my generation of the test results. I don't expect any surprise in those test results, tho... OK, will try to be prompt on the reviewing part. Can I ask you a favor for the testing you do: if possible please record configure and make all check output, config.log, tests/testsuite.log, and test-suite.log (will be present when parallel-tests patch is merged) for later sending to the autobuild server. That would be helpful. I think I'll have my autobuild patch and grand submit plan ready soonish, but even without the patch submissions should work. Thanks, Ralf
Re: autobuild logs for Libtool
* Ralf Wildenhues wrote on Mon, Aug 09, 2010 at 08:50:55PM CEST:
I think Libtool should use Autobuild, http://josefsson.org/autobuild/,
for testing, and developers as well as users should be encouraged to
send results to the gathering site. It's about time I try to get my
various build setups sorted out in some manner suitable for that.
OK to commit?
The AB_INIT invocation causes something like this extra info to appear
in the configure output:
configure: autobuild project... GNU Libtool
configure: autobuild revision... 2.2.11a (1.3227 2010-08-09)
configure: autobuild hostname... fuchs
configure: autobuild mode... default
configure: autobuild timestamp... 20100822T183040Z
When you don't have autobuild installed, thus AB_INIT not defined,
the patch should be a no-op. autobuild will still be usable without
the above output, it's just that the developer then needs to explicitly
provide the information as command-line arguments to autobuild.
I'd rather avoid adding libltdl/m4/autobuild.m4 to our git, that might
introduce version conflicts in the future.
A better long-term solution would be to start using gnulib-tool (for
argz, autobuild, maybe eventually bootstrap), but I *really* don't want
to start experimenting with that option before the release.
Thanks,
Ralf
configure: use Autobuild AB_INIT if available.
* configure.ac: Call AB_INIT if it is defined, with
$autobuild_mode as argument, to be set at configure time.
Set AB_VERSION to the Libtool version string.
* HACKING: Update.
* libltdl/m4/.gitignore: Ignore autobuild.m4.
diff --git a/HACKING b/HACKING
index 7ea1818..19b4b66 100644
--- a/HACKING
+++ b/HACKING
@@ -601,7 +601,9 @@ or obtained by writing to the Free Software Foundation,
Inc.,
(esp. bug-libtool) for outstanding bug reports also in the list of
pending moderation requests.
-* Make sure you have wget and lzma installed.
+* Make sure you have wget, lzma, and autobuild installed. aclocal should be
+ able to find autobuild.m4; or you can install it into the tree with
+ aclocal -I libltdl/m4 --install
* Make sure your locale is sane, e.g. by exporting LC_ALL=C.
@@ -717,8 +719,8 @@ or obtained by writing to the Free Software Foundation,
Inc.,
which will automatically propogate to http://planet.gnu.org.
--
- Copyright (C) 2004, 2005, 2006, 2007, 2008 Free Software Foundation,
- Inc.
+ Copyright (C) 2004, 2005, 2006, 2007, 2008, 2010 Free Software
+ Foundation, Inc.
Written by Gary V. Vaughan, 2004
This file is part of GNU Libtool.
diff --git a/configure.ac b/configure.ac
index 35c79f1..9690a05 100644
--- a/configure.ac
+++ b/configure.ac
@@ -127,6 +127,19 @@ dnl These are bootstrap requirements! Once built, libtool
may work with
dnl much older releases of autoconf and automake. See release notes.
AM_INIT_AUTOMAKE([1.10.1 gnu subdir-objects dist-lzma])
+
+## - ##
+## Autobuild initialisation. ##
+## - ##
+
+# You can set autobuild_mode at configure time to specify a unique
+# string for this build.
+: ${autobuild_mode=default}
+AB_VERSION=AC_PACKAGE_VERSION ($TIMESTAMP)
+m4_ifdef([AB_INIT],
+[AB_INIT([$autobuild_mode])])
+
+
dnl We use m4sh to generate libtool's portable shell scripts
AC_SUBST([M4SH], ['$(AUTOM4TE) --language=m4sh'])
diff --git a/libltdl/m4/.gitignore b/libltdl/m4/.gitignore
index 0b52c5c..81a1059 100644
--- a/libltdl/m4/.gitignore
+++ b/libltdl/m4/.gitignore
@@ -1 +1,2 @@
ltversion.m4
+autobuild.m4
proposed autobuild_mode naming scheme (was: autobuild logs for Libtool)
* Ralf Wildenhues wrote on Sun, Aug 22, 2010 at 08:38:19PM CEST: configure: autobuild mode... default [...] Autobuild uses a few strings to categorize log results: package version, $build, $host, hostname, time and date, and a so-called mode which my patch sets with the $autobuild_mode variable. I will be using something like the following values for $autobuild_mode. Suggestions and additions welcome, I think we could profit from a common, recognizable scheme: that way, when different people all mail their results to the autobuild site, results become more easily comparable. Here's the scheme: $autobuild_mode is - either 'default' (when the user forgets, or knows no better ;-) or a hyphen-separated string denoting: - the compiler vendor (gcc, llvm, clang, xl, hp, sun, sgi, dec, intel, pgi, msvc), - the binutils vendor (bfd or gold, native), and then zero or more features from the following list, in that order, and denoting that configure was passed the respective arguments: - shared --disable-static - static --disable-shared - pic--with-pic - nonpic --without-pic - fast --enable-fast-install - nofast --disable-fast-install - rtlruntimelinking on AIX (LDFLAGS=-Wl,-brtl) - c++CC=g++ - ltoCC='gcc -flto' CXX='gcc -flto' FC='gfortran -flto' F77='gfortran -flto' - lto-plugin same as lto with gold, but also LDFLAGS=-fuse-linker-plugin (or '-O4 -use-gold-plugin' with llvm) - ksh/ksh93/dash/... CONFIG_SHELL=/bin/ksh was set in the environment and /bin/ksh was used to call configure - debian-X.Y/gentoo-X.Y/rhel-X.Y/ubuntu-X.Y/... distribution (maybe including version) that was used (for those systems where $host is not distinguishing) - ac-X.Y/am-X.Z Autoconf and Automake versions used (if interesting) - pmake/gmake setting MAKE=pmake and running the build with $MAKE rather than the native make. So, for example, using GCC on AIX 5.2 with the system ld and runtimelinking, $host would be powerpc-aix53-.., my autobuild_mode would be gcc-native-rtl I'm not yet sure whether and when to leave out the compiler and binutils vendor strings; on some systems there is one canonical choice and there would be no need to distinguish. Not sure if the vendor one would always be the best default though. Additions welcome. Cheers, Ralf
Re: proposed autobuild_mode naming scheme (was: autobuild logs for Libtool)
Hallo Ralf,
I think this is an excellent idea... and not a moment too soon :)
On 23 Aug 2010, at 01:44, Ralf Wildenhues wrote:
* Ralf Wildenhues wrote on Sun, Aug 22, 2010 at 08:38:19PM CEST:
configure: autobuild mode... default
[...]
Autobuild uses a few strings to categorize log results: package version,
$build, $host, hostname, time and date, and a so-called mode which my
patch sets with the $autobuild_mode variable.
I will be using something like the following values for $autobuild_mode.
Suggestions and additions welcome, I think we could profit from a
common, recognizable scheme: that way, when different people all mail
their results to the autobuild site, results become more easily
comparable.
Here's the scheme:
$autobuild_mode is
- either 'default' (when the user forgets, or knows no better ;-)
or a hyphen-separated string denoting:
- the compiler vendor (gcc, llvm, clang, xl, hp, sun, sgi, dec, intel, pgi,
msvc),
Is the compiler version number interesting? (or the os release number for
native compilers with a hard to extract version string)
- the binutils vendor (bfd or gold, native),
and then zero or more features from the following list, in that order,
and denoting that configure was passed the respective arguments:
- shared --disable-static
- static --disable-shared
- pic--with-pic
- nonpic --without-pic
- fast --enable-fast-install
- nofast --disable-fast-install
- rtlruntimelinking on AIX (LDFLAGS=-Wl,-brtl)
- c++CC=g++
I often run on machines with no f77,gfortran,gcj etc:
- nof77test -z ${F77}
- nofc test -z ${FC}
- nogcjtest -z ${GCJ}
- rc test -n ${RC}
(picking the no-ness to minimize the mode string length in the common case)
- ltoCC='gcc -flto' CXX='gcc -flto' FC='gfortran -flto' F77='gfortran
-flto'
- lto-plugin same as lto with gold, but also LDFLAGS=-fuse-linker-plugin
(or '-O4 -use-gold-plugin' with llvm)
- ksh/ksh93/dash/...
CONFIG_SHELL=/bin/ksh was set in the environment and
/bin/ksh was used to call configure
- debian-X.Y/gentoo-X.Y/rhel-X.Y/ubuntu-X.Y/...
distribution (maybe including version) that was used
(for those systems where $host is not distinguishing)
- ac-X.Y/am-X.Z
Autoconf and Automake versions used (if interesting)
- pmake/gmake
setting MAKE=pmake and running the build with $MAKE rather
than the native make.
Instead of using 'default' as the default, we can make things a lot more
accurate with something along the lines of (off the top of my head, and
completely untested!):
: ${autobuild_mode=$host}
case $enable_shared,$enable_static,-$autobuild_mode- in
*,*,*-static-*) ;;
no,yes,*) autobuild_mode=$autobuild_mode-static ;;
esac
case $enable_shared,$enable_static,-$autobuild_mode- in
*,*,*-shared-*) ;;
yes,no,*) autobuild_mode=$autobuild_mode-shared ;;
esac
case $pic_mode,-$autobuild_mode- in
*,*-pic-*|*,*-nonpic-*) ;;
yes,*) autobuild_mode=$autobuild_mode-pic ;;
no,*) autobuild_mode=$autobuild_mode-nonpic ;;
esac
case $enable_fast_install,-$autobuild_mode- in
*,*-fast-*|*,*-nofast-*) ;;
yes,*) autobuild_mode=$autobuild_mode-fast ;;
no,*) autobuild_mode=$autobuild_mode-nofast ;;
esac
case $LDFLAGS,-$autobuild_mode- in
*,*-rtl-*) ;;
* -Wl,-brtl *,*) autobuild_mode=$autobuild_mode-rtl ;;
esac
case $CC,-$autobuild_mode- in
*,*-c++-*) ;;
g++*,*|c++*,*|xlC*,*|cxx*,*|CC*,*) # a list of all the C++ compiler we
support
autobuild_mode=$autobuild_mode-c++ ;;
esac
case $F77,-$autobuild_mode- in
,*-nof77-*) ;;
,*) autobuild_mode=$autobuild_mode-nof77 ;;
esac
case $FC,-$autobuild_mode- in
,*-nofc-*) ;;
,*) autobuild_mode=$autobuild_mode-nofc ;;
esac
case $GCJ,-$autobuild_mode- in
,*-nogcj-*) ;;
,*) autobuild_mode=$autobuild_mode-nogcj ;;
esac
case -$RC-,-$autobuild_mode- in
--,*|*,*-rc-*) ;;
-?*-,*) autobuild_mode=$autobuild_mode-rc ;;
esac
case $CC ,-$autobuild_mode- in
*,*-lto-*) ;;
* -flto ,*) autobuild_mode=$autobuild_mode-lto ;;
esac
... and so on.
This is long-wined enough too, I think, that putting it in a new
m4 macro rather than hard-coding into configure.ac seems worthwhile.
So, for example, using GCC on AIX 5.2 with the system ld and
runtimelinking, $host would be powerpc-aix53-.., my autobuild_mode would
be
gcc-native-rtl
I'm not yet sure whether and when to leave out the compiler and binutils
vendor strings; on some systems there is one canonical choice and there
would be no need to distinguish. Not sure if the vendor one would
always be the best default though.
Considering the amount of data we (or at least the autoconf and gnulib
list) collects about bugs in particular vendor compiler patch levels,
I think that it would be useful to capture this
Re: autobuild logs for Libtool
Hallo Ralf, On 23 Aug 2010, at 01:38, Ralf Wildenhues wrote: * Ralf Wildenhues wrote on Mon, Aug 09, 2010 at 08:50:55PM CEST: I think Libtool should use Autobuild, http://josefsson.org/autobuild/, for testing, and developers as well as users should be encouraged to send results to the gathering site. It's about time I try to get my various build setups sorted out in some manner suitable for that. OK to commit? My other comments on this thread notwithstanding, please go ahead... if you have time and inclination to automate the setting of autobuild_mode per those other comments before you push, so much the better. The AB_INIT invocation causes something like this extra info to appear in the configure output: configure: autobuild project... GNU Libtool configure: autobuild revision... 2.2.11a (1.3227 2010-08-09) is it about time we started using git-version-gen instead of our crazy CVS version number faking script? I'll do this before the pending release if you'd like. configure: autobuild hostname... fuchs configure: autobuild mode... default configure: autobuild timestamp... 20100822T183040Z When you don't have autobuild installed, thus AB_INIT not defined, the patch should be a no-op. autobuild will still be usable without the above output, it's just that the developer then needs to explicitly provide the information as command-line arguments to autobuild. I'd rather avoid adding libltdl/m4/autobuild.m4 to our git, that might introduce version conflicts in the future. Agreed. A better long-term solution would be to start using gnulib-tool (for argz, autobuild, maybe eventually bootstrap), Ack. but I *really* don't want to start experimenting with that option before the release. Strongly agreed! configure: use Autobuild AB_INIT if available. * configure.ac: Call AB_INIT if it is defined, with $autobuild_mode as argument, to be set at configure time. Set AB_VERSION to the Libtool version string. * HACKING: Update. * libltdl/m4/.gitignore: Ignore autobuild.m4. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: autobuild logs for Libtool
* Gary V. Vaughan wrote on Mon, Aug 23, 2010 at 05:04:18AM CEST: On 23 Aug 2010, at 01:38, Ralf Wildenhues wrote: * Ralf Wildenhues wrote on Mon, Aug 09, 2010 at 08:50:55PM CEST: OK to commit? My other comments on this thread notwithstanding, please go ahead... Thanks, done. if you have time and inclination to automate the setting of autobuild_mode per those other comments before you push, so much the better. Later. The AB_INIT invocation causes something like this extra info to appear in the configure output: configure: autobuild project... GNU Libtool configure: autobuild revision... 2.2.11a (1.3227 2010-08-09) is it about time we started using git-version-gen instead of our crazy CVS version number faking script? Another thing that would benefit from using gnulib-tool. I'll do this before the pending release if you'd like. Just to let you know beforehand: that bit is tricky as well, so you might want to test it well. For example, it must not fail in sources extracted from a tarball, and it should not fail in a git checkout when git is not present. Cheers, Ralf
[PATCH] Fix syntax for cygwin-cross
libltdl/m4/argz.m4: Add quotes around variable, which may contain the multiword value 'guessing no'. --- argz.m4 has this interesting behavior on cygwin-cross: [[case $host_os in #( *cygwin*) lt_cv_sys_argz_works=no if test $cross_compiling != no; then lt_cv_sys_argz_works=guessing no else So, on cygwin cross the variable lt_cv_sys_argz_works has a value that contains spaces. Thus, without quotes around its value, 'test' complains that there are too many arguments. This should probably also go upstream to gnulib. libltdl/m4/argz.m4 |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/libltdl/m4/argz.m4 b/libltdl/m4/argz.m4 index 37c1b11..d1f4ec5 100644 --- a/libltdl/m4/argz.m4 +++ b/libltdl/m4/argz.m4 @@ -66,7 +66,7 @@ AS_IF([test -z $ARGZ_H], ;; #( *) lt_cv_sys_argz_works=yes ;; esac]]) - AS_IF([test $lt_cv_sys_argz_works = yes], + AS_IF([test $lt_cv_sys_argz_works = yes], [AC_DEFINE([HAVE_WORKING_ARGZ], 1, [This value is set to 1 to indicate that the system argz facility works])], [ARGZ_H=argz.h -- 1.7.1
