Re: libole2 (was Re: commit -- POW - Beginning the Binary ...)


Subject: Re: libole2 (was Re: commit -- POW - Beginning the Binary ...)
From: Dom Lachowicz (dominicl@seas.upenn.edu)
Date: Thu Mar 30 2000 - 17:33:54 CST


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.

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)

For the most part, these are already coded in ANSI C, so they might port
"right out of the box," but I wouldn't hold my breath. Anyone who's taken a
class in C could port these few things to the desired platform in minimal
time (though other parts of GLib - like threads - would be messy).

Dom



This archive was generated by hypermail 2b25 : Thu Mar 30 2000 - 17:33:55 CST