Subject: Re: libole2 (was Re: commit -- POW - Beginning the Binary ...)
From: James Montgomerie (email@example.com)
Date: Thu Mar 30 2000 - 18:02:11 CST
"Dom Lachowicz" wrote:
> Justin Bradford wrote:
> > > Do you know whether anyone's attempted to build libole2 on
> > > platforms? If not, that'll be one of the places we'll need to
> > > efforts.
> > libole2 makes use of GLib.
> > If we want libole2 without modifications, we'll have to link with
> > It's small and should be portable, however, so it might no be a
> > Anyway, just to let everyone know, in case they don't like that.
> Yeah, it makes use of GLib and some POSIX stuff (unistd.h, fnctl.h,
> sys/stat.h). GLib is fully ported to BeOS and Win32. The Gimp even
> both, for an idea of the port status/quality. For the win32 port of
> GLib, check out http://www.gimp.org/~tml/gimp/win32/
> I think the POSIX features are emulated in the CygWin (win32)
> which if I'm not mistaken, you already make use of. If not, it's a
> suite and not too large to link against hosted by Cygnus.
It's not the default build environment. I agree that it probably
wouldn't be too hard to get the bits we need from Cygnus though.
> There are plans/rumors of porting Gnumeric eventually to win32 based
> Gtk and GLib ports. In that case, they'll need to port libole2 as
> be nice if we took care of that ahead of time (though libole2 might
> win32 already if someone would like to give it a try... :-) If
> support is any good (as I hear it is), we should get that port
> free" too.
> The main issue I see here is lack of support for GLib or POSIX on
> Macintosh. I don't know of any ports in progress for either library.
> As you can see, unlike Jamie, I'm in favor of using GLib instead of
> re-inventing the wheel for platforms where it already exists. If we
> libole2 to work on the Mac, by porting the small needed portion of
> we'd be doing the Gtk project a favor at no real cost to us since
> alternative is to rewrite the necessary functionality ourselves for
> platform, which I think is stupid considering how GLib has already
> tested and proven on these platforms for years now. Plus that'd just
> code that we'd have to maintain...
> The actual subset of GLib that we'd need to port to any unsupported
> to get libole2 to work is pretty basic. From what I can see from the
> we'd need:
> g_return_if_fail, g_return_val_if_fail, g_assert, g_warning,
> GList (doubly linked list)
> gint, guint, gint32, gpointer, etc... typedefs for most standard
> and g_new, g_new0, g_malloc, g_malloc0, g_free (memory related
We have things like that in Abi and in WV already - I'd say we should
use the, instead of importing another library into the tree. Since (I
imagine) we're going to be changing libole2 a little anyway, why not
make it use our native types? (It'll make it easier to interface with
As Dom points out though, it /would/ be friendlier to the libole people
(and would possibly make using future updates of libole within AbiWord
and WV easier) to port glib.
I'm not totally against uding glib, and if we go down that road I won't
complain afterwards. It just seems to me to not be 'reinventing' the
wheel, but bloating the source tree by adding more wheels when we've
some perfectly good working (cross-platform) ones already [and that
applies especially to platforms without a glib port already - is
morphing libole2 to WV and Abi more work than cross-platforming glib?].
Jamie -> Master of mixed metaphors! Or something.
This archive was generated by hypermail 2b25 : Thu Mar 30 2000 - 18:02:21 CST