Re: Merging gio into glib

[Ryan Lortie <desrt desrt ca>]

On Wed, 2007-11-07 at 17:45 +0200, Xan wrote:
> On Nov 7, 2007 5:35 PM, Alexander Larsson <alexl redhat com> wrote:
> > The idea is that this library would contain non-ui stuff that
> > applications want but that requires GObject, so they can't be in glib.
> > Various names for this library has been thrown about:
> >  gfoundation, gbase, gplatform
> 
> Would it be again one module and multiple so or only one so? If it's
> the former, how does it improve things? If the latter, what about
> people interested in gio but not in gsettings (for example)?
> 
> (Maybe I'm missing something, but the benefits are not really clear to me)

One library, one .so file, one pkg-config file.

"glib" as the package (ie: what's in the tar file) would then contain 5
libraries: glib, gobject, gmodule, gthread and gfoundation (or
whatever).  Each of these would have their own .so and their own
pkg-config.

The benefit is that we remove some linker overhead and also make it
easier to add new things to our "below GTK" platform in the future
instead of making a new library every time.  Additionally, there is no
real penalty if you want to use gio and not GSettings since many others
on the system are probably already using GSettings and it's all in
shared memory anyway...

GTK+ would then depend on gfoundation.  GTK+ is going to consume the
GSettings and gio interfaces, so the alternative is to have GTK+ depend
on them as separate libraries (either inside or outside of the glib
tarball).  In the "outside glib" case it complicates the build of our
platform and in the "inside glib" case it results in a tonne of
libraries inside glib that each cause additional linking overheads.

Hope that clears up the intention a bit.

Cheers