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

Reply via email to