Subject: Re: libole2 (was Re: commit -- POW - Beginning the Binary ...)
From: James Montgomerie (jamie@montgomerie.net)
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
non-Unix
> > > platforms? If not, that'll be one of the places we'll need to
focus our
> > > efforts.
> >
> > libole2 makes use of GLib.
> > If we want libole2 without modifications, we'll have to link with
GLib.
> > It's small and should be portable, however, so it might no be a
concern.
> > 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
runs on
> both, for an idea of the port status/quality. For the win32 port of
Gtk and
> GLib, check out http://www.gimp.org/~tml/gimp/win32/
>
> I think the POSIX features are emulated in the CygWin (win32)
environment,
> which if I'm not mistaken, you already make use of. If not, it's a
GPL'd
> 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
on TML's
> Gtk and GLib ports. In that case, they'll need to port libole2 as
well. It'd
> be nice if we took care of that ahead of time (though libole2 might
work on
> win32 already if someone would like to give it a try... :-) If
BeOS's
POSIX
> support is any good (as I hear it is), we should get that port
almost
"for
> free" too.
>
> The main issue I see here is lack of support for GLib or POSIX on
the
Apple
> 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
our
> re-inventing the wheel for platforms where it already exists. If we
need
> libole2 to work on the Mac, by porting the small needed portion of
GLib over,
> we'd be doing the Gtk project a favor at no real cost to us since
our
> alternative is to rewrite the necessary functionality ourselves for
each
> platform, which I think is stupid considering how GLib has already
been
> tested and proven on these platforms for years now. Plus that'd just
be more
> code that we'd have to maintain...
>
> The actual subset of GLib that we'd need to port to any unsupported
platform
> to get libole2 to work is pretty basic. From what I can see from the
sources,
> we'd need:
>
> g_return_if_fail, g_return_val_if_fail, g_assert, g_warning,
g_error
> macros
> GList (doubly linked list)
> gint, guint, gint32, gpointer, etc... typedefs for most standard
types
> GArray
> and g_new, g_new0, g_malloc, g_malloc0, g_free (memory related
macros and
> functions)
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
wv).
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
got
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