glib comments

Havoc Pennington hp at redhat.com
Tue Feb 25 01:10:51 GMT 2003


Hi,

Reading archives, I'm not on the list, just wanted to throw in .02 on
this since I am fairly familiar with GLib:

> It's not acceptable becuase it's different from the entire rest of
> KDE.  KDE multimedia systems are not a world to their own.  We're
> not to be less portable than the rest of KDE, less consistent than
> the rest of KDE, or anything of the sort.  Any KDE apps hould be
> able to use KDE multimedia resources.  Throwing up some
> out-of-the-blue C library requirement greatly hinders that.

Regarding portability, GLib should not be an issue; it runs on win32,
HPUX, SCO, Solaris, *BSD, OS X, etc. (basically GLib *is* a
portability layer).

Probably portability of gstreamer would be worse without GLib, since
gstreamer would need to reproduce all the portability layer provided
by GLib.

> Oh, while I'm thinking of it, does glib guarantee binary compatibility
> for the lengths of time that a major KDE version lasts?

GLib guarantees binary compatibility literally forever; when the ABI
changes every file installed by GLib is renamed or moved. See
http://ometer.com/parallel.html for some of the background on that.

So right now you would link to -lglib-2.0, but for old GLib there's
-lglib-1.2 still installed. You can compile against and link against
and run against GLib 1.2 even though GLib 2.0 has been out for I think
a couple years now.

-lglib-3.0 probably won't appear for another couple years from now (so
new ABIs that require the rename/move are typically introduced every
4-5 years).


To me the real point about GLib is this thought experiment:

 - imagine you write all your own custom equivalents for glib in
   gstreamer, and don't use glib

 - now imagine you cut-and-paste the glib code you need into gstreamer

 - now explain the difference between those two cases

To me if there's no difference there, the real issue is just whether
you want to cut-and-paste/static-link vs. dynamically link to glib.
For example pkg-config sucks in its own copy of GLib so people won't
complain about the dependency. (Of course now they complain about it
having its own copy, but you can't win ;-)


Well, I don't know anything about multimedia, but hopefully the above
is useful information about GLib policies/intentions.

Havoc



More information about the kde-multimedia mailing list