Subject: Re: PATCH: Compilation with LIBXML2 was broken
From: Sam TH (firstname.lastname@example.org)
Date: Mon Feb 05 2001 - 11:49:10 CST
On Mon, Feb 05, 2001 at 12:11:02PM -0500, Thomas Fletcher wrote:
> That is different than the decision about which XML parser
> we are going to bind into our application. If we were
> providing DLL support and could at run time attempt to
> bind in expat _or_ libxml based on what was available, that
> would be really cool. Our shared distribution right now
> links against shared objects. If the shared object isn't
> there then it isn't there and your application doesn't run.
> We can't have one application that optionally chooses to
> use a shared object based on what is on the system without
> DLL's. Thus we would be forced to build two applications
> one which links against expat, one that links against libxml.
> Now take this argument and iterate with spelling libraries,
> ispell vs pspell etc. That means that now we have four
> possiblities ... add another variable option and the build
> requirements for distribution grow further.
> My argument is that we should pick a "winner" and decide
> that it suits our needs (size, speed, portability) and
> then work with that project to improve it or guarantee
> its existance. I'm not just advocating this for our XML
> parser, but also for things like our spelling system.
There are a few issues here:
1) expat vs libxml
Expat is smaller, probably faster, and more portable. However, lots
of people already have libxml on their systems. libxml also provides
lots more features, but we currently don't use any of them.
The real problem here is that the SAX API was never standardized for
C. Durn Java folks.
But it's unlikely that any of the above facts are going to change. So
I think we are stuck with the libxml/expat split. However, When I
Finish Autoconf(tm), we will be able to autodetect them. No more
2) ispell vs aspell
Ispell sucks. The api is horrible, the code is old, unmaintained, and
slow. It supports no interesting features. But it has a large
installed base, and lots of hash files. Also, pspell and aspell
haven't been ported to all of our platforms.
If we could fix the latter of those problems, I for one would be happy
to move to pspell permanently. Anyone want to work on the porting?
3) Shared libraries in general
It's really too bad that we have to have so many modules in the CVS
tree. But it's because all those backwards platforms don't have the
nicely available tools that I can no longer live without (eg, apt).
On my machine, it's currently possible to build with just abi and wv
checked out, and hopefully the need for wv will be removed soon. But
we will always have to have that stuff around in CVS, until MS starts
shipping wv with Windows 2006. :-)
This archive was generated by hypermail 2b25 : Mon Feb 05 2001 - 11:48:33 CST