glib dependancy in KDE3.x

[Owen Taylor]

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
 capabilities)

 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 
 binaries.

 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
 pkg-config :-)


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, 
 etc.

 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.)

Regards,
                                        Owen