On Tue, 5 Aug 2003, Daniel Stenberg wrote:

> On Mon, 4 Aug 2003, David Byron wrote:
>
> > The real issue here is that runtests.pl has a routine called
> > subVariables that swaps %PWD for whatever the pwd command
> > spits out. pwd is a cygwin program that knows about /cygdrive/c, etc.
> > However, the standalone windows version of curl doesn't know how to
handle
> > that.
>
> Right, since the script needs to know where it runs to be
> able to create a proper URL that finds the test file.
>
> > I can write a patch to runtests.pl to make it call cygpath with -w.
>
> Well, that would make the stand-alone test depend on a
> specific cygwin tool. I don't see the benefit with that approach.

I agree, at least partly. Currently, the test suite seems to depend on at
least autoconf, make, gcc, and perl. Oh yeah, and pwd. All of these are
unix-ish. My goal isn't to get the whole test suite to run on plain
Windows. I think that would be really hard, and time not well spent.
Cygwin is a great tool and I think it's OK to depend on it. Maybe not for
cygpath, but for the other stuff for sure.

Assuming it's OK to depend on the above tools, I see a couple of different
ways of proceeding on getting the testsuite to run under cygwin but testing
a Windows binary:

1. remove %PWD from the tests. This affects tests 200, 201, 202, and 502 as
far as I can tell. I doubt this is OK, but maybe. Test 201 is for testing
a missing file so that one is probably pretty easy to rewrite.

Just found the -a switch the runtests.pl and 200 and 202 are the only
failures. The 500-series tests don't run yet though as I can't get the code
in tests/libtest to build yet. Anyway, maybe this is the easiest way
forward.

2. Implement a pwd program for Windows and ship it with curl. Maybe we can
create pwd.bat that calls cd or some such icky thing. I would really rather
avoid this.

3a. Somehow make the testsuite aware that it's testing a plain Windows
binary.

3b. Make sure to give the right path to curl. If it's OK to assume we're
using cygwin to do this (and I think it is), then calling cygpath seems OK.
It depends on how we do 3a though.

#3 is my preference, but I'm curious how to do 3a. Can we use one of the
standard args to configure? Which one? Should we add a new configure
switch for this? That might cover it.

> > $ ../src/curl
> file://localhost/c:/src/cobra/curl/tests/log/test200.txt
> >
> doesn't work for me.
> >
> > $ ../src/curl
> file://c:/src/cobra/curl/tests/log/test200.txt
> >
> > does work.
>
> Right, having drive letters in file URLs doesn't work in
> curl. I haven't really noticed this before... I think it
> happens because the path is prefixed with a slash which it
> shouldn't be in this case. Care to write up a fix for it?

Didn't realize this at first. The fix is a patch to libcurl, separate from
the test suite. Looks like somewhere in the block of code that starts at
line 1929 of url.c (1.290) is the place. I may have time to give this a
shot. Do you want to include drive letter parsing for all platforms, or
should I put something inside #if (defined) WIN32?

Beyond url.c, it looks like Curl_file_connect in file.c should "just work."
Do you agree?

-DB

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
Received on 2003-08-05