From: Jordan Henderson (jhenderson@daynt1.daas.dla.mil)
Date: Thu Jul 06 2000 - 12:34:43 EDT
> -----Original Message-----
> From: David Doolin [mailto:doolin@cs.utk.edu]
> Sent: Thursday, July 06, 2000 11:26 AM
> To: xml@rpmfind.net
> Cc: doolin@cs.utk.edu
> Subject: Re: [xml] Compile error libxml2-2.1.1/WIN32
>
>
>
> In message
> <C02C9AA5C528D411A7840060B057CE011D2FAC@daynt1.daas.dla.mil>,
> Jordan Henderson writes:
> >
> >I recently built libxml2-2.0.0 under Cygwin 1.1.2, a POSIX
> >environment built on GCC and GNU tools. The build went without
> >problems, but it failed a number of tests. I haven't had time
> >to look into it any more than this.
> >
> >In theory, you could have a set of XML tools built on Win32 using
> >Cygwin that would not risk becoming dependent on any MS tools.
>
> This is worthy.
>
> But, remember some of us have to use ms tools such as msvc, so
> whatever cygwin changes are needed should play nicely
> with msvc compilable changes.
I'm not opposed to someone maintaining any changes necessary
for Visual C++, etc. Someone mentioned the possibility of
using the command line Borland compilers, too. I thought that
this was a good place to mention the Cygwin possibility.
I am concerned that once you start becoming dependent on msvc,
you get into situations like what has happened with ActiveState
Perl. Now, I have nothing against ActiveState. They've done
an _excellent_ job. I am concerned that their toolset having
unique MS-Windows utilities and options could end up eventually
forking the Perl code base and world. MS gives ActiveState
funding and MS has tried to fragment the Java through embrace
and extend.
I hope we can agree that any changes necessary to support Win32
would be completely compatible from the API standpoint with the Unix
code base.
If the Cygwin environment works as intended, there wouldn't be
any changes from the Unix sources necessary. Of course, this
is not always possible and a lot of sources "ported" to work
under Cygwin have changes that conflict with the msvc
compilers, often involving incorrect use of "#ifdef WIN32" when
a Cygwin specific #ifdef was what was required.
I completely agree that if libxml were made to work with
Cygwin that care should be taken not to conflict with msvc
changes.
I'm also in sympathy with Erwin Rol's concerns surrounding
Cygwin. In many ways it is an immature environment and I
wonder if it will ever be useful for programs upon which
people can depend. Although, you can distribute binaries
built on Cygwin with a DLL that doesn't require one
to install the compiler and environment. Also, there is
the MINGW32 set of tools, which is the GNU tools and
compilers using the MS C DLLs. This is another flavor
that might be investigated.
>
> Also, nothing personal here, so don't take it so...
> For those of us limited to ms tools, not having libxml
> means linking ms xml parser.
> So there is a bit of give and take here.
This is a _very_ good point.
I think we're in agreement here, but I would like to
point out that having options surrounding using libxml on
Win32 environments (msvc built, Cygwin, Borland, etc.) is
also a good in that it gives people who wish to
use libxml in Windows environments more flexibility.
For example, it's probably easier to get Unix sources, that
might make libxml calls, working quickly under Cygwin (and
similar environments) than under msvc.
>
> Thanks,
> Dave D
>
> ----
Thanks,
Jordan Henderson
---- Message from the list xml@xmlsoft.org Archived at : http://xmlsoft.org/messages/ to unsubscribe: echo "unsubscribe xml" | mail majordomo@xmlsoft.org
This archive was generated by hypermail 2b29 : Wed Aug 02 2000 - 12:30:22 EDT