Subject: libole2, glib et al...
From: Caolan McNamara (cmc@stardivision.de)
Date: Fri Mar 31 2000 - 01:50:02 CST
While libole2 is currently small, it is rather important that there be
a single ole2 library. Reasons are that there are a stack of dodgy
ole2 documents that will break some of each of the libole2 libraries
and programs, some also break the windows one as well of course :-),
but some work in windows and fail with other libraries. ole2 is a
small and critical function and it would be good to share it as much
as possible to share bug for bug compatability with the windows one.
Im delighted that libole2 is to be sprung from its cvs prison. I think
its important that projects be brought out of cvs and into a
standalone ./configure run tarball on a regular basis, otherwise you
tend to kind of think that its dissappeared or that work as ceased on
it. Regular appearances of stuff on freshmeat sparks the memory.
Previously I had intended to move wv on top of libole2 but I balked a
little at the glib dependancy. Wv should compile under windows/vax and
amiga pretty much as easily as under unix so I wondered about moving
some of the required glib bits into wv the same way I did the
ImageMagick thing, i.e. fall back to a tiny inbuilt subset if
configure cannot find it. The catch was that the linked lists require
glibs own memory functions which do a lot of memory block fiddling, so
I ended up with most of glib inside wv, which was a bit silly. Though
I haven't looked at it in a while so I could be just wrong. So
methinks that it would be cleaner to
a) port glib to any new platforms that might show up that it hasn't
already been ported to or
b) make the linked lists in libole2 be either glib ones or custom ones
depending on a compile time flag.
b sounds like an awful bit of work for little gain, and the libole2
guys might feel you are just wasting their time, as for a) I would
think that the ideal situation for libole2 in the future would be for
it to be able at configure time to realize that it is in windows and
use the native windows ole2 stuff, so in that case it wouldn't need to
use special glib stuff while under windows. Cunning eh?,
My vote would be for adding the dependancy of glib, with the
aspiration that in the future glib as required by libole2 might not be
required on systems that have native ole2 support, i.e. windows. Under
linux abi is gtk which already needs glib so theres going to be no
extra dependancies for you at all. Theres some crazed photon person
wandering around the list, isn't there?, but I assume that glib will
install smoothly for him so we'll all be happy. You could make it a
POW to make libole2 use the native ole2 calls under windows, for some
reason that would amuse me to no end.
C.
This archive was generated by hypermail 2b25 : Fri Mar 31 2000 - 01:49:57 CST