Subject: Re: libole2 (was Re: commit -- POW - Beginning the Binary ...)
From: Paul Rohr (paul@abisource.com)
Date: Thu Mar 30 2000 - 18:11:04 CST
At 06:33 PM 3/30/00 -0500, Dom Lachowicz wrote:
>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).
Cool!
As Dom points out, all of the potential portability problems with glib come
in the portions of glib that libole2 doesn't need or use (such as threads
and other POSIX stuff that goes beyond the vanilla ANSI C calls we all know
and love).
By contrast, this subset looks very, very small and utterly vanilla. So,
what do people think of the following modest proposal?
Fork this tiny subset of glib and include it in libole2.
That way, we can easily ensure that everything is ported properly. And, for
environments which do have a functioning glib implementation, it shouldn't
take much makefile magic to link against the real thing instead of this
subset.
Paul
This archive was generated by hypermail 2b25 : Thu Mar 30 2000 - 18:05:32 CST