Re: Unify line endings in localization test
Den 2009-01-21 23:09, skrev Ralf Wildenhues:
* Peter Rosin wrote on Tue, Jan 20, 2009 at 12:34:57AM CET:
Den 2009-01-19 21:35 skrev Ralf Wildenhues:
This looks a bit hackish. We already have a handful of places which we
fixed up in order to avoid line ending issues. This one looks hackish
enough to deserve being wrapped in a macro (in testsuite.at, below
LT_AT_HOST_DATA?), so that future instances of this issue can easily be
handled likewise.
Something like the attached?
Yes, with nits below addressed.
--- a/tests/testsuite.at
+++ b/tests/testsuite.at
@@ -204,6 +204,19 @@ case $host_os in mingw*)
esac])
+# LT_AT_UNIFY_NL(FILE, [RESULT-FILE])
+#
Let's underline the whole text. :-)
+# Ensure (text) file has predicable line endings.
FILE. Please describe RESULT-FILE. Typo "predictable".
+m4_define([LT_AT_UNIFY_NL],
+[case $host_os in
+ mingw*)
+ tr -d '\015' < $1 > m4_ifval([$2], [$2], [$1.t
+ mv -f $1.t $1]) ;; m4_ifval([$2], [
+ *)
+ mv -f $1 $2 ;;])
+esac])
1 or 2 characters of indentation? ;-)
An even easier-to-use interface would be an LT_AT_CHECK_FF or so,
which would check after converting to a standard file format.
But the above is good enough, and easy enough to use, and the
full solution would require us to hack up more, with LT_AT_EXEC_CHECK
and all. So let's use this.
Hi Ralf,
Thanks for the review!
Ok, so push to master or pr-msvc-support? And one more thing I just
realized, on MinGW the two-arg version leaves FILE intact which does
not happen for other hosts. Should that be fixed? With an rm for MinGW
or with cp instead of the mv for others?
Cheers,
Peter
2009-01-22 Peter Rosin
Unify line endings in localization test.
* tests/testsuite.at: Update copyright year.
(LT_AT_UNIFY_NL): Add macro that unifies line endings on
platforms that suffer from such confusion.
* tests/localization.at: Use it. Update copyright year. Fixes
the test on MSYS/MSVC.
diff --git a/tests/localization.at b/tests/localization.at
index d489fef..92b19ac 100644
--- a/tests/localization.at
+++ b/tests/localization.at
@@ -1,6 +1,6 @@
# localization.at -- libtool and locales-*- Autotest -*-
#
-# Copyright (C) 2008 Free Software Foundation, Inc.
+# Copyright (C) 2008, 2009 Free Software Foundation, Inc.
# Written by Ralf Wildenhues, 2008
#
# This file is part of GNU Libtool.
@@ -43,13 +43,16 @@ AT_CHECK([$CC $CPPFLAGS $CFLAGS -c b.c || exit 77], [],
[stdout], [stderr])
# Find out about expected output.
AT_CHECK([$CC $CPPFLAGS $CFLAGS -c a.c || exit 1], [1], [stdout], [stderr])
-mv -f stdout expected-stdout
-mv -f stderr expected-stderr
+LT_AT_UNIFY_NL([stdout], [expected-stdout])
+LT_AT_UNIFY_NL([stderr], [expected-stderr])
AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c a.c ||
exit 1],
[1], [stdout], [stderr])
+LT_AT_UNIFY_NL([stderr])
AT_CHECK([diff expected-stderr stderr])
LTBASE=`$ECHO "$LIBTOOL" | sed 's,^.*/,,'`
-AT_CHECK([grep -v "^$LTBASE: compile" stdout | diff expected-stdout -])
+grep -v "^$LTBASE: compile" stdout > libtool-stdout
+LT_AT_UNIFY_NL([libtool-stdout])
+AT_CHECK([diff expected-stdout libtool-stdout])
# check that we get our quoting right.
LANGUAGE='a; nosuchprogram " '\'' & $x /#+*(){}|,:`\ !%'
diff --git a/tests/testsuite.at b/tests/testsuite.at
index f116a1f..7c3ee73 100644
--- a/tests/testsuite.at
+++ b/tests/testsuite.at
@@ -1,6 +1,6 @@
# Process with autom4te to create an -*- Autotest -*- test suite.
#
-# Copyright (C) 2004, 2005, 2006, 2007, 2008 Free Software
+# Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009 Free Software
# Foundation, Inc.
# Written by Gary V. Vaughan, 2004
#
@@ -204,6 +204,20 @@ case $host_os in mingw*)
esac])
+# LT_AT_UNIFY_NL(FILE, [RESULT-FILE])
+# ---
+# Ensure (text) FILE has predictable line endings.
+# If RESULT-FILE is not given, convert in-place.
+m4_define([LT_AT_UNIFY_NL],
+[case $host_os in
+ mingw*)
+tr -d '\015' < $1 > m4_ifval([$2], [$2], [$1.t
+mv -f $1.t $1]) ;; m4_ifval([$2], [
+ *)
+mv -f $1 $2 ;;])
+esac])
+
+
# LT_AT_EXEC_CHECK(EXECUTABLE, [STATUS = 0], [STDOUT], [STDERR],
# [ARGS-OR-STATUS-ADJUST])
# --
Re: "Run tests with low max_cmd_len" on MSYS/MSVC
Den 2009-01-21 22:54, skrev Ralf Wildenhues: Hi Peter, * Peter Rosin wrote on Wed, Jan 21, 2009 at 02:26:36AM CET: This patch together with [1] and [2] will make "Run tests with low max_cmd_len" on MSYS/MSVC behave the same as the individual tests. The patch fixes a couple more of the /abs/path issues already fixed in [1] and [2]. However, I fear that these hunks may be more controversial, as they touch code that affects other platforms as well. Well, for non-w32 systems the patch is pretty obviously ok, as func_to_host_path doesn't do much there, and not slowly. :-) For Cygwin and MinGW, it will likely make things much slower, since this will cause lots of forks. Indeed. From a correctness perspective, the patch looks good to go, though. For MinGW yes, for Wine this is probably not needed (Wine allows opening both posix and win32 files in its CreateFile implementation), and for Cygwin it is probably at least theoretically wrong (but it might work, I don't know how liberal open is in Cygwin...) As soon as you try to use Cygwin to launch native Win32 programs you are on thin ice. So, libtool on Cygwin should IMHO assume that the MinGW toolchain is a Cygwin hosted MinGW targeting toolchain. If the MinGW toolchain is like that - and I believe that both the soon historic "gcc -mno-cygwin" as well as the new "i686-pc-mingw32-gcc" toolchains are - then libtool has no business tampering with the posix paths using "cygpath -w" in these cases. Maybe there should be a second (optional) arg to func_to_host_path that indicates why you want to convert the path? Or perhaps a new func_to_toolchain_path that only converts the path if the toolchain isn't really for $host? I.e. is instead running in some kind of emulator or in some other subsystem or otherwise has a different notion of paths (like MSVC on MSYS). But when to use func_to_toolchain_path would be system specific as it is only needed on MSYS when MSYS for one reason or another fails to convert the path (an /absolute/path is stored in a command file or appears after some prefix on the command line that MSYS doesn't recognize, e.g. -out:/absolute/path). On Cygwin it would be needed for all /absolute/paths passed to the toolchain. On Wine it wouldn't be wrong to do as on Cygwin, but it would perhaps be overkill to always convert as Wine handles posix paths in CreateFile. Cheers, Peter
Re: spaces
Le 19 janv. 09 à 23:38, Ralf Wildenhues a écrit : Bonjour Ralf! It is true that I have been disturbed and even annoyed by tab vs. space in some patches that gave the impression of improper indentation. Therefore, for a year or so, I am now using spaces only. But it is not sufficient for Libtool if you are the only one who uses spaces. I was actually promoting the space-only approach for the libtool coding style, not claiming that I would do it regardless of the decision :) And it is probably not helpful for email readability if new lines are spaces and old lines are tabs for indentation. Transitions are always a PITN, but it's for a better future :) Well, changing Libtool over to use spaces only is quite a diff, and not a trivial one to check, either. Agreed, but it can be done incrementally. Or we can start by converting all the leading spaces, I fail to see a reason for a tab to be required there. Let alone that it increases ltmain.sh by more than 10% in size, which will probably even have an impact on runtime performance. Hum... From 425171194b41e6627aae75f18dfa5620e8a8c34d Mon Sep 17 00:00:00 2001 From: Akim Demaille Date: Mon, 19 Jan 2009 09:05:31 +0100 Subject: [PATCH] Clean space uses. * libtoolize.m4sh: Remove trailing spaces. Use , as some editors remove "useless" spaces in . This patch is ok, feel free to push. Will do, thanks.
Re: spaces
Den 2009-01-21 23:13, skrev Ralf Wildenhues: * Charles Wilson wrote on Tue, Jan 20, 2009 at 07:29:52PM CET: Bob Friesenhahn wrote: For many years I have had my editor configured to always use spaces. This ensures WYSIWYG for everyone involved. Agree 100%. I try to manually match whatever sp/tab convention is in place -- using vi if I have to -- but much prefer all spaces. OK so it seems there are more voices for spaces. Can we agree to make the switch only after 2.2.8 though, I would like to avoid unnecessary churn ATM. I have no strong preference regarding indentation, except that if the msvc branch is to be merged soon after 2.2.8, I'd much prefer to do it before any extensive whitespace cleanup. Cheers, Peter
testsuite performance (was: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89.)
* Charles Wilson wrote on Wed, Jan 21, 2009 at 08:47:42PM CET: > [...] EVERY separate patchset requires an independent full testsuite > run. Until recently, that was 5 hours of sitting in front of my > computer waiting for popups, while that computer was completely useless > for anything else (100% cpu). That is horrible. May I ask what kind of CPU you have, and which Cygwin version? Can you work on a Linux system with Wine, for at least those changes for which the difference shouldn't matter that much? Can you work on a GCC cfarm system for those tests where Cygwin isn't a premium, and ask the people running the mingw-w64 system for an account to test there? FWIW, on a two-way system here, the Libtool testsuite finishes in a little less than 6 minutes. However that is a bit cheated, as it uses parallel Autotest (from git Autoconf) and as yet unpublished parallel Automake TESTS (yes I need to clean up patches for Automake and Libtool and publish them). On a GCC compile farm 8-way I think I brought the test suite below a minute at one time, when excluding stress test and low max_cmd_len test. These two tests need to be split up and/or moved earlier in the suite in order to allow for better parallelism. Cheers, Ralf
Re: spaces
On Thu, 22 Jan 2009, Peter Rosin wrote: > Den 2009-01-21 23:13, skrev Ralf Wildenhues: > > * Charles Wilson wrote on Tue, Jan 20, 2009 at 07:29:52PM CET: > > > Bob Friesenhahn wrote: > > > > For many years I have had my editor configured to always use > > > > spaces. This ensures WYSIWYG for everyone involved. > > > Agree 100%. I try to manually match whatever sp/tab convention is in > > > place -- using vi if I have to -- but much prefer all spaces. > > > > OK so it seems there are more voices for spaces. Or maybe it just seems so because those that want a change are those that will speak up. I prefer tabs. If I want the text in the 25th column it's just 3 tab keys and start typing. I don't have to count out pressing the space bar 24 times and then wondering if it really was 24. I find python code really annoying because it is spaces only. But then again, maybe I don't count. After all, I'm not a large contributor to libtool. > > Can we agree to make the switch only after 2.2.8 though, > > I would like to avoid unnecessary churn ATM. > > I have no strong preference regarding indentation, except that if > the msvc branch is to be merged soon after 2.2.8, I'd much prefer > to do it before any extensive whitespace cleanup. > > Cheers, > Peter -- Tim RiceMultitalents(707) 887-1469 t...@multitalents.net
Re: Unify line endings in localization test
Hi Peter, * Peter Rosin wrote on Thu, Jan 22, 2009 at 10:57:20AM CET: >>> Something like the attached? >> >> Yes, with nits below addressed. > Ok, so push to master or pr-msvc-support? This change is ok for both. However, let's move away from manual addition of the same change to more than one public branch. How about you do either one of these: 1) create, in your own repository, a new branch pr-tests-newline-fixes containing this one patch, then merge this patch into both pr-msvc-support and into master, then push the last two (no need to ever push pr-tests-newline-fixes), 2) add the patch to master and merge master into pr-msvc-support, and then push both branches, 3) or, if you feel unsure, I can do either of (1) or (2) for you. I'd recommend that you use the git-merge-changelog driver from gnulib for merging ChangeLog entries, and I would also like to see that log entries appear in in the ChangeLog file in the order that patches are applied to master. Whether they contain updated dates or not, I am not so sure about, but I think GCS encourages that. So merging of the ChangeLog might entail a bit of manual work after all. > And one more thing I just > realized, on MinGW the two-arg version leaves FILE intact which does > not happen for other hosts. Should that be fixed? Yes. And the resulting semantics documented in the macro header. Good catch. > With an rm for MinGW or with cp instead of the mv for others? Hmm. cp? Thanks, Ralf > 2009-01-22 Peter Rosin > > Unify line endings in localization test. > * tests/testsuite.at: Update copyright year. > (LT_AT_UNIFY_NL): Add macro that unifies line endings on > platforms that suffer from such confusion. > * tests/localization.at: Use it. Update copyright year. Fixes > the test on MSYS/MSVC.
Re: "Run tests with low max_cmd_len" on MSYS/MSVC
* Bob Friesenhahn wrote on Thu, Jan 22, 2009 at 02:04:07AM CET: > On Wed, 21 Jan 2009, Ralf Wildenhues wrote: >> >> We may need to think about speeding up func_to_host_path, e.g., by not >> forking for arguments that don't need conversion, or by converting >> several paths with a constant amount of forks. But that can be done >> separately. > > There is also the possibility of building a translation cache which is > preserved across libtool invokations. The only concern is if the mounts > get changed after the cache is generated. Indeed, that seems like a viable possibility, too. I still think just excluding obviously safe cases will help in the vast majority of practical cases: e.g.: - file names without any directory separators, - relative file names (in those cases where no conversion between directory separators is needed). Cheers, Ralf
Re: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89.
* Charles Wilson wrote on Thu, Jan 22, 2009 at 04:14:51AM CET:
> Ralf Wildenhues wrote:
>
> > I don't see a need to skip the test elsewhere. Here's what I'd do:
> > transform $LIBTOOL to have CFLAGS and LTCFLAGS also contain -std=c89
> > -Werror. (The test would be even cleaner with a re-configured libtool,
> > but let's not go overboard here.)
>
> Being a total novice with autotest, I couldn't figure out how to do the
> former, so I did the latter. Attached is my first attempt. It probably
> should be named something other than 'c89 test' because that name
> implies building all of libtool (including libltdl) with -std=c89. But I
> couldn't think of anything else to call it.
Let's let it test both c89 and c99 (and maybe other restrictive options
later, as users report them). So how about we call it cwrapper test,
because that's what it's supposed to test, and put it in a file named
cwrapper.at?
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -467,6 +467,7 @@ TESTSUITE_AT = tests/testsuite.at \
> tests/indirect_deps.at \
> tests/archive-in-archive.at \
> tests/execute-mode.at \
> + tests/c89.at \
> tests/infer-tag.at \
> tests/localization.at \
> tests/install.at \
Order here is good.
> --- a/tests/c89.at2006-11-30 19:00:00.0 -0500
> +++ b/tests/c89.at2009-01-21 21:32:01.79210 -0500
> +AT_SETUP([c89 test])
> +AT_KEYWORDS([libtool])
> +# make sure existing libtool is configured for shared libraries
> +AT_CHECK([$LIBTOOL --features | grep 'disable shared libraries' && (exit
> 77)],
> + [1], [ignore])
No need for the subshell for exit, BTW. This test isn't strictly
needed, but of course helps avoid the test on some systems where we
shouldn't use a cwrapper. BTW2, in your version of the patch you could
even let your sub configure script have --enable-shared although the
user --disable'd it for the Libtool tree. But anyway.
The following could be wrapped in
orig_CFLAGS=$CFLAGS
orig_LIBTOOL=$LIBTOOL
for restrictive_flags in '-std=c89 -Werror' '-std=c99 -Werror'; do
CFLAGS="$orig_CFLAGS $restrictive_flags"
sed "s/LTCFLAGS=.*/&' $restrictive_flags'/" < $orig_LIBTOOL > ./libtool
LIBTOOL=./libtool
...
done
> +# make sure CFLAGS -std=c89 -Werror do not cause a failure
> +# themselves (e.g. because a non-gcc compiler doesn't support
> +# those flags).
> +AT_DATA([trivial.c],
> +[[
> +int main (void)
> +{
> + return 0;
> +}
> +]])
> +AT_CHECK([$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -std=c89 -Werror -c
> trivial.c || exit 77],[0],[ignore],[ignore])
I'd just make this
$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c trivial.c || continue
then.
Then, let's drop configure.ac, Makefile.am, and just
> +AT_DATA([liba.c],
> +[[int liba_func1 (int arg)
> +{
> + return arg + 1;
> +}
> +]])
> +AT_DATA([usea.c],
> +[[extern int liba_func1(int arg);
> +int main (void)
> +{
> + int a = 2;
> + int b = liba_func1 (a);
> + if (b == 3) return 0;
> + return 1;
> +}
> +]])
AT_CHECK([$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c liba.c],
[], [ignore], [ignore])
AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o liba.la -rpath /foo
liba.lo],
[], [ignore], [ignore])
AT_CHECK([$CC $CPPFLAGS $CFLAGS -c usea.c],
[], [ignore], [ignore])
AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o usea$EXEEXT usea.$OBJEXT
liba.la],
[], [ignore], [ignore])
> +AT_CHECK([test -f liba.la])
> +LT_AT_EXEC_CHECK([./usea], [0], [ignore], [ignore], [])
> +
> +AT_CLEANUP
Can you test those changes for me, please (TESTSUITEFLAGS='-v -d -x -k
cwrapper')
and ensure that test passes, but only with your ltmain patch applied?
Thanks,
Ralf
Re: spaces
On Thu, 22 Jan 2009, Tim Rice wrote: Or maybe it just seems so because those that want a change are those that will speak up. I prefer tabs. If I want the text in the 25th column it's just 3 tab keys and start typing. I don't have to count out pressing the space bar 24 times and then wondering if it really was 24. I find python code really annoying because it is spaces only. Almost anyone will prefer tabs if they are the only ones working on the source code. The problems occur when several/many people are working on shared source code using a variety of editors. Can we agree to make the switch only after 2.2.8 though, I would like to avoid unnecessary churn ATM. I am in favor of instituting a rule that all new code and patch code should use spaces but that existing TABs can continue to exist until those specific regions of code are edited. The formatting situation is not worse than now (we probably already have mixed spaces and tabs) and eventually the code will entirely use spaces. Bob == Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Unify line endings in localization test
Den 2009-01-22 21:54 skrev Ralf Wildenhues:
Hi Peter,
* Peter Rosin wrote on Thu, Jan 22, 2009 at 10:57:20AM CET:
Something like the attached?
Yes, with nits below addressed.
Ok, so push to master or pr-msvc-support?
This change is ok for both. However, let's move away from manual
addition of the same change to more than one public branch. How about
you do either one of these:
1) create, in your own repository, a new branch pr-tests-newline-fixes
containing this one patch, then merge this patch into both
pr-msvc-support and into master, then push the last two (no need to ever
push pr-tests-newline-fixes),
2) add the patch to master and merge master into pr-msvc-support, and
then push both branches,
3) or, if you feel unsure, I can do either of (1) or (2) for you.
I commited the attached using method 1. However I felt I had to base
the new branch on the common ancestor of master and pr-msvc-support
in order to get a clean(er) merge into both branches. Also, I should
perhaps have used a different merge message? I thought it looked ok
in my local repo, but that was only because the temporary branch exists
there, right?
Cheers, and thanks for the hand-holding,
Peter
diff --git a/ChangeLog b/ChangeLog
index 9ba522d..3ac3e4b 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2009-01-22 Peter Rosin
+
+ Unify line endings in localization test.
+ * tests/testsuite.at: Update copyright year.
+ (LT_AT_UNIFY_NL): Add macro that unifies line endings on
+ platforms that suffer from such confusion.
+ * tests/localization.at: Use it. Update copyright year. Fixes
+ the test on MSYS/MSVC.
+
2008-12-19 Akim Demaille
Fix copyright notice.
diff --git a/tests/localization.at b/tests/localization.at
index d489fef..92b19ac 100644
--- a/tests/localization.at
+++ b/tests/localization.at
@@ -1,6 +1,6 @@
# localization.at -- libtool and locales-*- Autotest -*-
#
-# Copyright (C) 2008 Free Software Foundation, Inc.
+# Copyright (C) 2008, 2009 Free Software Foundation, Inc.
# Written by Ralf Wildenhues, 2008
#
# This file is part of GNU Libtool.
@@ -43,13 +43,16 @@ AT_CHECK([$CC $CPPFLAGS $CFLAGS -c b.c || exit 77], [],
[stdout], [stderr])
# Find out about expected output.
AT_CHECK([$CC $CPPFLAGS $CFLAGS -c a.c || exit 1], [1], [stdout], [stderr])
-mv -f stdout expected-stdout
-mv -f stderr expected-stderr
+LT_AT_UNIFY_NL([stdout], [expected-stdout])
+LT_AT_UNIFY_NL([stderr], [expected-stderr])
AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c a.c ||
exit 1],
[1], [stdout], [stderr])
+LT_AT_UNIFY_NL([stderr])
AT_CHECK([diff expected-stderr stderr])
LTBASE=`$ECHO "$LIBTOOL" | sed 's,^.*/,,'`
-AT_CHECK([grep -v "^$LTBASE: compile" stdout | diff expected-stdout -])
+grep -v "^$LTBASE: compile" stdout > libtool-stdout
+LT_AT_UNIFY_NL([libtool-stdout])
+AT_CHECK([diff expected-stdout libtool-stdout])
# check that we get our quoting right.
LANGUAGE='a; nosuchprogram " '\'' & $x /#+*(){}|,:`\ !%'
diff --git a/tests/testsuite.at b/tests/testsuite.at
index f116a1f..56ca3a2 100644
--- a/tests/testsuite.at
+++ b/tests/testsuite.at
@@ -1,6 +1,6 @@
# Process with autom4te to create an -*- Autotest -*- test suite.
#
-# Copyright (C) 2004, 2005, 2006, 2007, 2008 Free Software
+# Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009 Free Software
# Foundation, Inc.
# Written by Gary V. Vaughan, 2004
#
@@ -204,6 +204,20 @@ case $host_os in mingw*)
esac])
+# LT_AT_UNIFY_NL(FILE, [RESULT-FILE])
+# ---
+# Ensure (text) FILE has predictable line endings.
+# If RESULT-FILE is given, FILE is left untouched. If not, convert in-place.
+m4_define([LT_AT_UNIFY_NL],
+[case $host_os in
+ mingw*)
+tr -d '\015' < $1 > m4_ifval([$2], [$2], [$1.t
+mv -f $1.t $1]) ;; m4_ifval([$2], [
+ *)
+cp $1 $2 ;;])
+esac])
+
+
# LT_AT_EXEC_CHECK(EXECUTABLE, [STATUS = 0], [STDOUT], [STDERR],
# [ARGS-OR-STATUS-ADJUST])
# --
Re: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89.
Ralf Wildenhues wrote: > Can you test those changes for me, please (TESTSUITEFLAGS='-v -d -x -k > cwrapper') > and ensure that test passes, but only with your ltmain patch applied? Works fine, with a few additional changes. I'll post as a patch on a separate thread shortly. -- Chuck
[PATCH] Add tests for cwrapper with -std=c89 and -std=c99
* tests/cwrapper.at: New file.
* Makefile.am: Add tests/cwrapper.at.
---
Ok to push?
Makefile.am |1 +
tests/cwrapper.at | 81 +
2 files changed, 82 insertions(+), 0 deletions(-)
create mode 100644 tests/cwrapper.at
diff --git a/Makefile.am b/Makefile.am
index 790..7a61846 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -467,6 +467,7 @@ TESTSUITE_AT= tests/testsuite.at \
tests/indirect_deps.at \
tests/archive-in-archive.at \
tests/execute-mode.at \
+ tests/cwrapper.at \
tests/infer-tag.at \
tests/localization.at \
tests/install.at \
diff --git a/tests/cwrapper.at b/tests/cwrapper.at
new file mode 100644
index 000..2cae611
--- /dev/null
+++ b/tests/cwrapper.at
@@ -0,0 +1,81 @@
+# cwrapper.at -- test compliance with c89 standard -*- Autotest -*-
+
+# Copyright (C) 2009 Free Software Foundation, Inc.
+# Written by Charles Wilson, 2009
+#
+# This file is part of GNU Libtool.
+#
+# GNU Libtool is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# GNU Libtool is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GNU Libtool; see the file COPYING. If not, a copy
+# can be downloaded from http://www.gnu.org/licenses/gpl.html,
+# or obtained by writing to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+
+
+AT_SETUP([wrapper for uninstalled dynamically linked executables - C])
+AT_KEYWORDS([libtool])
+
+# make sure existing libtool is configured for shared libraries
+AT_CHECK([$LIBTOOL --features | grep 'disable shared libraries' && exit 77],
+[1], [ignore])
+
+AT_DATA([trivial.c],
+[[
+int main (void)
+{
+ return 0;
+}
+]])
+AT_DATA([liba.c],
+[[int liba_func1 (int arg)
+{
+ return arg + 1;
+}
+]])
+AT_DATA([usea.c],
+[[extern int liba_func1 (int arg);
+int main (void)
+{
+ int a = 2;
+ int b = liba_func1 (a);
+ if (b == 3) return 0;
+ return 1;
+}
+]])
+
+orig_CFLAGS=$CFLAGS
+orig_LIBTOOL=$LIBTOOL
+for restrictive_flags in '-std=c89 -Werror' '-std=c99 -Werror'; do
+ CFLAGS="$orig_CFLAGS $restrictive_flags"
+ sed "s/LTCFAGS=.*/&' $restrictive_flags'/" < "$orig_LIBTOOL" > ./libtool
+ LIBTOOL=./libtool
+
+ # make sure $restrictive_flags do not cause a failure
+ # themselves (e.g. because a non-gcc compiler doesn't them)
+ $LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c trivial.c || continue
+
+ AT_CHECK([$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c liba.c],
+ [], [ignore], [ignore])
+ AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -version-info=0.0.0
-no-undefined -o liba.la -rpath /foo liba.lo],
+ [], [ignore], [ignore])
+ AT_CHECK([test -f liba.la])
+
+ AT_CHECK([$CC $CPPFLAGS $CFLAGS -c usea.c],
+ [], [ignore], [ignore])
+ AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o usea$EXEEXT
usea.$OBJEXT liba.la],
+ [], [ignore], [ignore])
+ LT_AT_EXEC_CHECK([./usea], [0], [ignore], [ignore], [])
+done
+
+AT_CLEANUP
+
--
1.6.0.4
Re: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89.
Charles Wilson wrote: > The bits removed from this commit are attached as > "cygwin-cwrapper-cleanups.patch". Will start a new thread with these cleanups. -- Chuck
Re: testsuite performance
Ralf Wildenhues wrote: > * Charles Wilson wrote on Wed, Jan 21, 2009 at 08:47:42PM CET: >> [...] EVERY separate patchset requires an independent full testsuite >> run. Until recently, that was 5 hours of sitting in front of my >> computer waiting for popups, while that computer was completely useless >> for anything else (100% cpu). > > That is horrible. May I ask what kind of CPU you have, and which Cygwin > version? Core2Duo T5450 (1.66GHz) Vista 32bit Home Cygwin-1.5.25 or 1.7.38 (parallel installs; speed more or less the same) Vista @ 1.66G x 2 cores (my current laptop) seems to be about the same speed as XP @ 433MHz x 1 core (my previous laptop) -- in general, /not/ cygwin-specific. Sad, isn't it? What I try to do now is run long-running stuff on the "old" laptop since it's still humming away in the corner...but I don't have cygwin-1.7 installed on that one. > Can you work on a Linux system with Wine, for at least those > changes for which the difference shouldn't matter that much? Can you > work on a GCC cfarm system for those tests where Cygwin isn't a premium, > and ask the people running the mingw-w64 system for an account to test > there? Sure, I can always run tests on a linux system; that would ensure that any changes I make don't break linux; this tells me nothing about *cygwin*. Unfortunately, wine won't really help, as it'd still go thru the cygwin layer, THEN the wine (not-an-) emulator layer, before the splendiferously fast linux system gets a crack at doing anything. There's really no way around testing on cygwin other than testing on cygwin. Ditto for mingw: ya gotta test under MSYS (which is cygwin-really-old by another name). Even mingw-w64: you still need an MSYS shell and utilities to run all the test cases, compare the results, etc. The problem is that test suites, in general, are THE worst performance case for cygwin: a bunch of tiny file accesses and TONS of tiny fork-n-execs (this is why cygwin/mingw get a disproportionate speed boost whenever you succeed in reducing the number of forks in libtool). But process spawning behavior is one of the biggest differences between win32 and posix, and one of the most difficult (and thus, relatively slow and inefficient) for cygwin/msys to paper over. It's been a thorn in our sides for over a decade. However, you think libtool is bad: it took me almost a week to run the gcc test suite. I've only ever done that twice. Dave Korn (cygwin-gcc maintainer) oughta take up a collection for a dedicated machine... -- Chuck
Re: [PATCH] Add tests for cwrapper with -std=c89 and -std=c99
Charles Wilson wrote: > + sed "s/LTCFAGS=.*/&' $restrictive_flags'/" < "$orig_LIBTOOL" > ./libtool I've already fixed this typo s/LTCFAGS/LTCFLAGS/ -- Chuck
[PATCH] [cygwin|mingw] cwrapper cleanups.
libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src) [file scope]: re-organized includes and portability macros. Avoid oldnames on MINGW32 and MSVC for setmode/stat/chmod/getcwd/putenv. Declare _putenv on MINGW32 when -ansi. Use namespaced macro LT_DEBUGWRAPPER. --- This patch contains the parts excluded from http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg4.html as described here: http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00105.html (with some additional modifications). For discussion of the motivation of this patch, see http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00101.html and look for "Part (2) is a bit unobvious when merely looking" about one-third down. It's interesting that on mingw, when -std=c89, there is no declaration of putenv (or _putenv) in the system headers. However, with -Werror the compilation of the wrapper succeeds even without this patch -- but there is an error: if (putenv (str) != EXIT_SUCCESS) You have to turn on -Wall (with -std=c89) to get mingw gcc to complain: In function `lt_setenv': warning: implicit declaration of function `putenv' However, in -std=c99 mode, this warning is printed /without/ -Wall. So, the cwrapper.at tests (which exercise both '-std=c89 -Werror' and '-std=c99 -Werror', will fail on mingw without this patch or something like it. libltdl/config/ltmain.m4sh | 60 +-- 1 files changed, 40 insertions(+), 20 deletions(-) diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index 3f1a30c..d525893 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -2716,18 +2716,11 @@ EOF # include # include # include -# define setmode _setmode #else # include # include # ifdef __CYGWIN__ # include -# define HAVE_SETENV -# ifdef __STRICT_ANSI__ -char *realpath (const char *, char *); -int putenv (char *); -int setenv (const char *, const char *, int); -# endif # endif #endif #include @@ -2741,6 +2734,44 @@ int setenv (const char *, const char *, int); #include #include +/* declarations of non-ANSI functions */ +#if defined(__MINGW32__) +# ifdef __STRICT_ANSI__ +int _putenv (const char *); +# endif +#elif defined(__CYGWIN__) +# ifdef __STRICT_ANSI__ +char *realpath (const char *, char *); +int putenv (char *); +int setenv (const char *, const char *, int); +# endif +/* #elif defined (other platforms) ... */ +#endif + +/* portability defines, excluding path handling macros */ +#if defined(_MSC_VER) +# define setmode _setmode +# define stat_stat +# define chmod _chmod +# define getcwd _getcwd +# define putenv _putenv +# define S_IXUSR _S_IEXEC +# ifndef _INTPTR_T_DEFINED +# define _INTPTR_T_DEFINED +# define intptr_t int +# endif +#elif defined(__MINGW32__) && !defined(__MINGW32CE__) +# define setmode _setmode +# define stat_stat +# define chmod _chmod +# define getcwd _getcwd +# define putenv _putenv +#elif defined(__CYGWIN__) +# define HAVE_SETENV +# define FOPEN_WB "wb" +/* #elif defined (other platforms) ... */ +#endif + #if defined(PATH_MAX) # define LT_PATHMAX PATH_MAX #elif defined(MAXPATHLEN) @@ -2756,19 +2787,12 @@ int setenv (const char *, const char *, int); # define S_IXGRP 0 #endif -#ifdef _MSC_VER -# define S_IXUSR _S_IEXEC -# define stat _stat -# ifndef _INTPTR_T_DEFINED -# define intptr_t int -# endif -#endif - #ifndef DIR_SEPARATOR # define DIR_SEPARATOR '/' # define PATH_SEPARATOR ':' #endif +/* path handling portability macros */ #if defined (_WIN32) || defined (__MSDOS__) || defined (__DJGPP__) || \ defined (__OS2__) # define HAVE_DOS_BASED_FILE_SYSTEM @@ -2794,10 +2818,6 @@ int setenv (const char *, const char *, int); # define IS_PATH_SEPARATOR(ch) ((ch) == PATH_SEPARATOR_2) #endif /* PATH_SEPARATOR_2 */ -#ifdef __CYGWIN__ -# define FOPEN_WB "wb" -#endif - #ifndef FOPEN_WB # define FOPEN_WB "w" #endif @@ -2811,7 +2831,7 @@ int setenv (const char *, const char *, int); } while (0) #undef LTWRAPPER_DEBUGPRINTF -#if defined DEBUGWRAPPER +#if defined LT_DEBUGWRAPPER # define LTWRAPPER_DEBUGPRINTF(args) ltwrapper_debugprintf args static void ltwrapper_debugprintf (const char *fmt, ...) -- 1.6.0.4
Re: Unify line endings in localization test
* Peter Rosin wrote on Fri, Jan 23, 2009 at 12:01:00AM CET: > Den 2009-01-22 21:54 skrev Ralf Wildenhues: >> >> 1) create, in your own repository, a new branch pr-tests-newline-fixes >> containing this one patch, then merge this patch into both >> pr-msvc-support and into master, then push the last two (no need to ever >> push pr-tests-newline-fixes), > I commited the attached using method 1. However I felt I had to base > the new branch on the common ancestor of master and pr-msvc-support > in order to get a clean(er) merge into both branches. OK. That way you did not merge the rest of master's current changes into pr-msvc-support. I would not have minded if you had done that, either, but it doesn't matter. > Also, I should > perhaps have used a different merge message? I thought it looked ok > in my local repo, but that was only because the temporary branch exists > there, right? The message was just fine. gitk --all looks good here. Thanks, Ralf
Re: [PATCH] Add tests for cwrapper with -std=c89 and -std=c99
* Charles Wilson wrote on Fri, Jan 23, 2009 at 12:36:57AM CET: > * tests/cwrapper.at: New file. > * Makefile.am: Add tests/cwrapper.at. > --- > Ok to push? Yes, with really minor nits: > --- /dev/null > +++ b/tests/cwrapper.at > @@ -0,0 +1,81 @@ > +AT_SETUP([wrapper for uninstalled dynamically linked executables - C]) This message is a bit long, and thus will look ugly in the test output. How about just cwrapper for uninstalled executables so that we can use "cwrapper" as keyword for choosing this test; it should be specific enough to tell users what it is about (and it doesn't matter here whether this wrapper is for some form of linking only). > +orig_CFLAGS=$CFLAGS > +orig_LIBTOOL=$LIBTOOL > +for restrictive_flags in '-std=c89 -Werror' '-std=c99 -Werror'; do > + CFLAGS="$orig_CFLAGS $restrictive_flags" > + sed "s/LTCFAGS=.*/&' $restrictive_flags'/" < "$orig_LIBTOOL" > ./libtool > + LIBTOOL=./libtool > + > + # make sure $restrictive_flags do not cause a failure > + # themselves (e.g. because a non-gcc compiler doesn't them) s/them)/understand &/ > + $LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c trivial.c || continue Please go ahead and push with these changes. Thank you, Ralf
Small patch for the QNX platform
Hello! This patch adds qnx as platform which supports library version information. diff -u -r ./libtool-2.2.6/libltdl/config/ltmain.m4sh ./libtool-2.2.6-qnx/libltdl/config/ltmain.m4sh --- ./libtool-2.2.6/libltdl/config/ltmain.m4sh 2008-09-07 20:54:53.0 +0300 +++ ./libtool-2.2.6-qnx/libltdl/config/ltmain.m4sh 2009-01-23 08:01:41.0 +0200 @@ -5746,7 +5746,7 @@ # which has an extra 1 added just for fun # case $version_type in - darwin|linux|osf|windows|none) + darwin|linux|osf|windows|qnx|none) func_arith $number_major + $number_minor current=$func_arith_result age="$number_minor" With best regards, Mike Gorchak. E-mail: m...@malva.ua libtool-qnx.diff Description: Binary data
Re: Small patch for the QNX platform
Hello Mike, * Mike Gorchak wrote on Fri, Jan 23, 2009 at 07:09:18AM CET: > This patch adds qnx as platform which supports library version information. Thanks for your patch. First off, I have almost no knowledge of QNX, so I rely on help. As far as I can see, this patch changes the versioning scheme used on QNX. This means, that potentially all libraries created with libtool after this change are incompatible with all of those created before. I see you supplied the last QNX-related change to Libtool, too, in 2004. Can you provide information about why this change is needed now? Did QNX change their versioning, or why is this necessary now? Also, we would be extremely interested in seeing testsuite (make -k check) output of Libtool on this system. Thanks, Ralf > diff -u -r ./libtool-2.2.6/libltdl/config/ltmain.m4sh > ./libtool-2.2.6-qnx/libltdl/config/ltmain.m4sh > --- ./libtool-2.2.6/libltdl/config/ltmain.m4sh 2008-09-07 > 20:54:53.0 +0300 > +++ ./libtool-2.2.6-qnx/libltdl/config/ltmain.m4sh 2009-01-23 > 08:01:41.0 +0200 > @@ -5746,7 +5746,7 @@ ># which has an extra 1 added just for fun ># >case $version_type in > - darwin|linux|osf|windows|none) > + darwin|linux|osf|windows|qnx|none) > func_arith $number_major + $number_minor > current=$func_arith_result > age="$number_minor" >
