On Wed, 2007-11-07 at 17:45 +0200, Xan wrote: > On Nov 7, 2007 5:35 PM, Alexander Larsson <[EMAIL PROTECTED]> 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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list