On Tue, 5 Aug 2003, David Byron wrote:

> > 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.

The test suite does not depend on autoconf and make, gcc and perl do not
explicitly force you to use cygwin.

> Oh yeah, and pwd.

Yeps, and if a test case fails 'diff' is used. And new programs are started
with a trailing & to make them start in the background...

> All of these are unix-ish.

Indeed. But if anyone can bring up ideas that makes it less unixish but still
functional, I'd be willing to adopt.

> 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:

I think it is OK, because your work brings the test suite forward a bit closer
to run on Windows. It is in the right direction, no doubt about it.

> 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.

file:// URLs need an absolute path. How can I get that to use in the test
cases without the use of pwd or an equivalent?

Hm, one way would of course be that the one who runs the test script provides
the "current directory" as an argument to the test script:

 ./runtests.pl /you/run/here

... which then on a windows box could be something like

 perl runtests.pl X:\temp\curl\secret\hideout

> 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.

I don't understand why perl doesn't offer this, when it offers a 'chdir'
function...

> 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.

It can be probably done quite easily by invoking 'curl -V' and checking the
output of the first line (which is including the CPU-OS-SYSTEM name detected
by configure, or the hardcoded 'win32' that the native-windows makefiles use).
The test script already invokes that exact command line (in the checkcurl
function) to figure out what the built curl supports.

> > 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.

Yes.

> Looks like somewhere in the block of code that starts at line 1929 of url.c
> (1.290) is the place.

I think you should do the drive letter code within the Curl_file_connect
function in lib/file.c, as that code already does some windows magic
convertions on the path.

> 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?

I'd like it #ifdef WIN32, since I know of no other still used platform that
supports drive letter prefixes like that.

-- 
 Daniel Stenberg -- curl: been grokking URLs since 1998
-------------------------------------------------------
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