Re: [Patch] Testing loads of cygwin1.dll from MinGW and MSVC, take 3
On Jun 9 14:54, Max Kaehn wrote: > On Thu, 2005-06-09 at 01:53, Corinna Vinschen wrote: > > On Jun 8 11:44, Max Kaehn wrote: > > > I wound up using "eval", and was thoroughly perplexed at the way > > > that the first "eval" seems to get thrown away. > > > > -v, please. > > > > tcsh> sh > > $ eval date > > Thu Jun 9 10:52:23 WEDT 2005 > > $ > > > > Corinna > > (I wasn't sure if you meant -v for version numbers > or verbose output; I hope what you wanted is somewhere in there.) I meant "please, be more verbose with information". > fulgurite-xpdbg% make -f /u/cygwin/src/winsup/testsuite/iterate.mak > results_foo=0 > results_bar=1 > results_baz=2 > results_foo = > results_bar = 1 > results_baz = 2 > results_foo = > [: 0: unknown operand > results_bar = 1 > make: *** [all] Error 1 I can reproduce it without having make involved. It looks like a ash bug. Oh boy, I didn't look into ash for ages. I'm somewhat in real life work, but I'll lok into it at one point. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc.
Re: [Patch] Testing loads of cygwin1.dll from MinGW and MSVC, take 3
On Fri, 10 Jun 2005, Corinna Vinschen wrote: > On Jun 9 14:54, Max Kaehn wrote: > > On Thu, 2005-06-09 at 01:53, Corinna Vinschen wrote: > > > On Jun 8 11:44, Max Kaehn wrote: > > > > I wound up using "eval", and was thoroughly perplexed at the way > > > > that the first "eval" seems to get thrown away. > > > > > > -v, please. > > > > > > tcsh> sh > > > $ eval date > > > Thu Jun 9 10:52:23 WEDT 2005 > > > $ > > > > > > Corinna > > > > (I wasn't sure if you meant -v for version numbers > > or verbose output; I hope what you wanted is somewhere in there.) > > I meant "please, be more verbose with information". > > > fulgurite-xpdbg% make -f /u/cygwin/src/winsup/testsuite/iterate.mak > > results_foo=0 > > results_bar=1 > > results_baz=2 > > results_foo = > > results_bar = 1 > > results_baz = 2 > > results_foo = > > [: 0: unknown operand > > results_bar = 1 > > make: *** [all] Error 1 > > I can reproduce it without having make involved. It looks like a ash bug. > Oh boy, I didn't look into ash for ages. I'm somewhat in real life work, > but I'll lok into it at one point. Is this related to CGF's query on cygwin@ about replacing sh=ash with sh=bash? If not, it should be. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
RE: [Patch] Testing loads of cygwin1.dll from MinGW and MSVC, take3
Original Message
>From: Max Kaehn
>Sent: 08 June 2005 19:44
> On Mon, 2005-06-06 at 16:51, Christopher Faylor wrote:
>> Actually neither is right. The tests are supposed to run to
>> completion, not stop on a failure.
>
> My first cut was this, but it could have led to a tedious
> accumulation of if/then/else/if/then/else:
> So I wrote a more general script, discovered that cygwin uses ash
> instead of bash for /bin/sh, and rewrote the more general script so
> ash could handle it. Since ash doesn't seem to support arrays,
> I wound up using "eval", and was thoroughly perplexed at the way
> that the first "eval" seems to get thrown away.
Look, if it's getting complicated and tricky, that argues for a bit of a
rethink / redesign, doesn't it?
So maybe this would be further support for the idea of not making cygload
a separate tool? runtest will already automatically recurse into every
subdir in winsup.api, and surely all you'd need to do would be patch
src/winsup/testsuite/winsup.api/winsup.exp to recognize the pattern
'cygload' in the path of a source file and compile and run it using slightly
different spawn commands. Something vaguely along these lines:
Index: winsup.exp
===
RCS file: /cvs/src/src/winsup/testsuite/winsup.api/winsup.exp,v
retrieving revision 1.14
diff -p -u -r1.14 winsup.exp
--- winsup.exp 12 Mar 2003 06:28:27 - 1.14
+++ winsup.exp 10 Jun 2005 17:07:50 -
@@ -48,7 +48,13 @@ foreach src [glob -nocomplain $srcdir/$s
clear_xfail
}
-ws_spawn "$CC -nodefaultlibs -nostdinc -mwin32 $CFLAGS $src
$add_includes $add_libs $runtime_root/binmode.o -lgcc
$runtime_root/libcygwin0.a -lkernel32 -luser32 -o $base.exe"
+regsub "^.*cygload.*$" $src "YES" is_cygload
+if { $is_cygload == "YES" } {
+ws_spawn "gcc -mno-cygwin $src -o $base.exe -lstdc++
-Wl,-e,[EMAIL PROTECTED]"
+} else {
+ ws_spawn "$CC -nodefaultlibs -nostdinc -mwin32 $CFLAGS $src
$add_includes $add_libs $runtime_root/binmode.o -lgcc
$runtime_root/libcygwin0.a -lkernel32 -luser32 -o $base.exe"
+}
+
if { $rv != "" } {
verbose -log "$rv"
fail "$testcase (compile)"
@@ -58,7 +64,12 @@ foreach src [glob -nocomplain $srcdir/$s
} else {
set redirect_output /dev/null
}
-ws_spawn "$rootme/cygrun ./$base.exe > $redirect_output"
+if { $is_cygload == "YES" } {
+ set windows_runtime_root [exec cygpath -m $runtime_root]
+ ws_spawn "./$base.exe -cygwin $windows_runtime_root/cygwin0.dll
> $redirect_output"
+} else {
+ ws_spawn "$rootme/cygrun ./$base.exe > $redirect_output"
+}
if { $rv != "" } {
verbose -log "$testcase: $rv"
fail "$testcase (execute)"
although this isn't quite correct or consistent, it serves to illustrate the
design I'd recommend.
Or is there something I haven't grasped that means cygload has to be
treated as a separate tool?
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: [Patch] Testing loads of cygwin1.dll from MinGW and MSVC, take3
On Fri, Jun 10, 2005 at 06:11:38PM +0100, Dave Korn wrote: >Look, if it's getting complicated and tricky, that argues for a bit of >a rethink / redesign, doesn't it? Yes. I was wondering why we were going down this path when we've both noted that maybe it wasn't a good idea. I would still prefer a generic "mingw" solution which is integrated with the rest of the test suite. cgf
