On Tue, 9 Mar 2004, Dominick Meglio wrote:

> > My intention, as long as Daniel et al agree, is to replace
> > the testcurl.sh shell script with the testcurl.pl perl
> > script permanently, to facilitate running on systems like
> > win32 without a bourne-like shell. For backwards
> > compatibility the testcurl.sh script could simply execute
> > testcurl.pl.
>
> I fail to see the advantage here. Just as Win32 doesn't come
> with sh, it doesn't come with perl either. So why make
> someone have to go and download perl.exe? Why not just make
> them go download bash.exe?
>
> You're not actually fixing the problem, you're making it
> worse (since you now have to do that hack with testcurl.sh
> to enable backwards compatibility) and you still require a
> 3rd party program to be installed on the system. I just
> don't see any benefit of this.

My two cents here is that the right 3rd party tool to require is cygwin.
I've gotten almost everything to work in this combo environment where you
run buildconf, and configure, but then use nmake to build the library and
source. With this, the testsuite builds and most of it even runs and
passes. The missing pieces I know about are:

- nmake Makefiles for building the stuff in tests/libtest
- some way to set environment variables in the testsuite so that an
MSVC-compiled version of curl.exe can see them.

That said, I haven't tried setting up an autobuild this way.

-DB
Received on 2004-03-09