This is the mail archive of the cygwin-patches@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 -0000      1.14
+++ winsup.exp  10 Jun 2005 17:07:50 -0000
@@ -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,_cygloadCRTStartup@0"
+    } 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....


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]