Subject: Re: libole2, glib et al...
From: Thomas Fletcher (thomasf@qnx.com)
Date: Fri Mar 31 2000 - 07:14:57 CST
On Fri, 31 Mar 2000, Caolan McNamara wrote:
>
[small size of libole2 snipped]
>
[comment on the sprining of code from cvs prisons removed]
>
> 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.
Is this a one or the other option? Why is it that we couldn't
provide a similar API to the glib list functions that don't do
all the memory block fiddling and use standard memory allocator.
I haven't looked at the glib code, but I find that we are really
starting to grow the size of AbiWord when we start adding in
all of these extra libs. I would be really interested to know
just how much of the functionality of the various components
we use (expat, wv, libiconv, libpng, zlib) and how much is
really just dead code ... hopefully optimized out, but you
never know.
> 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?,
Ahhh not configure! =;-) Configure is the greatest tool going ...
when it works. When it doesn't it is a nightmare. Right now
QNX/Neutrino should work just fine with 90% of the PD code out
there ... but configure doesn't properly guess the system type ...
even though patches have been sent to the maintainers of autoconf
that describe a QNX and Neutrino system it takes time for it
to filter out into the world. Even then when it does configure
right, we provide covers for our compilers (which are gcc) so
that invoking gcc directly doesn't give you the results that
you would expect ... command line options are messed up and
when the compiler underneath ain't gnu all sort of bad things
happen.
Sorry ... ranting a little off topic. I'd much rather that
we do a generic implementation for the glib people which
would increase the glib portability (ie no fancy memory
allocator ... just use the system one, no fancy list
management ... just use 1st year C), and can be toggled
with a #define.
> 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.
Yeah this crazed Photon person spent his life tracking
down instances of gint, gchar etc and changing them
while performing the Unix->QNX code conversion. The fact
that new we are thinking of putting glib into the tree
(which will presumably now mean that gint, gchar etc) are
now available amuses me to no end =;-)
I don't care so much about adding another dependancy to the
tree, but if that is the case we should seriously examine
the possibility of changing the Abi UT functions to be covers
or map directly to implmented glib functions. This way we
can leverage the presumed maintenance of glib.
Thomas
crazed photon person ... who abhors mmap()
-------------------------------------------------------------
Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Neutrino Development Group
(613)-591-0931 http://www.qnx.com/~thomasf
This archive was generated by hypermail 2b25 : Fri Mar 31 2000 - 07:15:08 CST