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