Subject: Re: libole2, glib et al...
From: Joaquín Cuenca Abela (cuenca@ie2.u-psud.fr)
Date: Fri Mar 31 2000 - 11:47:07 CST
Thomas Fletcher wrote:
>
> > 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 ...
But you can provide configure *AND* custom makefiles. If for some
systems configure is more apropiate than custom makefiles, the user can
use configure (and crush the abiword makefiles). And if for some
systems, configure don't works, the user can try his luck with the
abiword makefiles.
> 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.
/me thinks that the only utility for this stuff will be for embedded
systems...
just useful for save a bit of disk space, but anyways, I think that a
--mini-glib option may be useful...
>
> > 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 =;-)
And why not just:
#include <Im_tired_of_g_suffixes.h>
with:
#define gchar char
#define gint int
etc...
?
> 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.
I agree, if we use glib (and I'm for), I don't see the need for the Abi
UT functions.
-- Joaquín Cuenca Abela e-mail: cuenca@ie2.u-psud.fr
This archive was generated by hypermail 2b25 : Fri Mar 31 2000 - 11:47:21 CST