-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday February 24, 2003 05:10, Havoc Pennington wrote:
> Neil wrote:
> > 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).

The library naming really sidesteps the issue.  If glib 3.0 comes out 3 
months after KDE 4 comes out, and GStreamer development moves to it, then 
KDE gets stuck with an unmaintained version of glib and GStreamer for the 
life of KDE 4.  The compatibility within a version is nice, but we also 
need a library that will keep compatible for long stretches of time.

But, if glib versions will stay compatible for years, then I doubt that'd 
be a problem.  The issue then becomes GStreamer's own compatibility.

> 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, actually, I sorta like the idea of KDE users being able to build 
GStreamer with a static glib.  If we go with GStreamer I'll have to look 
at building it that way, and even packaging it all together for 
convenience. :-)

But linking isn't my complaint.  Developing is my complaint.  KDE 
developers shouldn't have to be glib developers.  KDE developers should be 
able to extend the KDE-chosen media system without learning some C 
toolkit.

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

It was useful.  Though I'd visited #gnome on irc.gnome.org just a couple 
hours ago and gotten basically the same ABI answer. :-)

thanks,
- -- 
Neil Stevens - neil@qualityassistant.com
"Distinctions by race are so evil, so arbitrary and insidious that a
state bound to defend the equal protection of the laws must not allow
them in any public sphere." -- Thurgood Marshall
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+WsoFf7mnligQOmERAr/9AJ4qAUUUuEpirjGRJkdmiQPAZv3vCwCfX8QB
AsrfNN01BuDezqpMAn/aPBk=
=wT5l
-----END PGP SIGNATURE-----

_______________________________________________
kde-multimedia mailing list
kde-multimedia@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-multimedia