On Wed, 2007-11-07 at 11:06 -0500, Ryan Lortie wrote: > > One library, one .so file, one pkg-config file.
I'd say do a hybrid: separate pkg-config files, single .so. You can even create .so symlinks, making it a build-time option to include a "feature" in the gwhatever.so or build a separate .so for it, and applications simply don't care. When that infrastructure is added, you can even have glib, gobject, and gmodule in the same .so too, or have separate ones. It's similar to what Qt does these days btw. Main problem with such a thing would be that applications will not be enforced to list all their used modules in their Makefile. To fix that, and to avoid polluting the namespace unnecessarily, each glib module will have its own header directory. So if you don't list gio in your Makefile.am, you can't include gio.h. If you think about the above layout, its separating the abstraction of what is a module from what happens to be going into a .so, and I like that distinction. I probably ask for some libtool support to make it easy to implement such schemes. You want libtool to do the symlink part for you... -- behdad http://behdad.org/ "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin, 1759 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list