glib dependancy in KDE3.x
otaylor at redhat.com
Fri Mar 7 14:58:39 GMT 2003
This thread was pointed out to me, and while I certainly
can't answer the question of whether KDE should depend
on GLib, I thought, as one of the GLib maintainers, I could
provide useful information on some of the points raised.
How portable is GLib?
Off the top of my head, recent versions of GLib (2.x.y)
have been compiled on at least:
Many flavors of Linux, *BSD, Win32 (native and cygwin),
Solaris, HP/UX, Tru64, OS X, IRIX, and QNX,
It's certainly easier on some platforms than others; on
Unix variants you have to deal with the dependencies on
GNU gettext and libiconv (or sufficiently similar native
Win32 is likely the hardest place to get GLib compiled,
because of the lack of a standardized compilation
environment, but Tor Lillqvist and others provide prebuilt
And of course, GLib is pretty widely used, so it's not
unlikely the user will already have it.
What if there were bugs that caused problems for a KDE release?
GLib historically has been relatively bug free (it consists
of lots of independent pieces, and many of the pieces haven't
changed much in years.) I can't think of any point when
a GLib issue has blocked a GNOME release.
But say there was a bug (or more likely, a compilation issue
on some target platform)? Well, a KDE release critical
issue would be at least as high priority for me as a
GNOME release critical issue; it just doesn't look good
for a library to have a major software project blocking on it.
Is pkg-config a huge pain to set up?
Being zero-pain to get going and zero-dependency is an explicit
goal of pkg-config; if there are problems., we'd certainly like
to know about it so we can fix them.
In general, as far as I can tell, pkg-config seems to be
doing well at its job at making compilation simple and robust.
I'll be neutral on the GLib question, but KDE should use
How big is GLib?
I've seen people here use the word "tiny" to refer to GLib.
To avoid unpleasant surprises ... no it isn't tiny. Compiled
libglib is ~400k and libgobject (if used) about ~200k more.
But if you aren't using, say, the Unicode normalization tables,
they should stay on disk.
(And if there is another program already running using GLib,
then any GLib overhead is shared.)
Does GLib just duplicate Qt/STL?
If you were programming in C++ and using Qt, you wouldn't
have much reason to use GLib. GLib probably has a few
things that Qt doesn't have (various standard Unicode
algorithms come to mind) but the bulk is in fact stuff
provided by Qt ... portability, containers, a main loop,
and so forth.
GLib does go substantially beyond the STL in areas like
Unicode handling, portable thread abstraction, the main loop,
system dependency hiding for things like process creation,
But presumably the reason for depending on GLib for KDE
wouldn't be to provide new functionality to KDE, but rather
for use in software components that were shared between KDE
software and non-KDE software. So, perhaps this simply
isn't a relevant question.
Anyways ... that's probably enough for now. I'd be happy
to answer further questions if people have them. (Please
Cc: me since I'm not on this list.)
More information about the kde-core-devel