On Mon, Dec 10, 2007 at 09:47:36PM +0100, Simon Richter wrote: >>> No, what can be done is to fix upstream's broken declaration that 'you can >>> assume glib functions are available when doing "#include <gtk/gtk.h>"'. It >>> doesn't follow that just because this works in practice, it should be a >>> supported usage.
>> When many of the types used by GTK+ are those provided by GLib, it >> sounds wrong to ask developers to include the GLib headers to have these >> types available. > If it is really expected that type declarations are to be shared between a > program and a library, then the program becomes dependent on the library's > ABI without this dependency being formally expressed in any usable form, > which is broken in and by itself. > GTK needs to provide its own definitions of types and not expose interfaces > it does not control. Fine in theory, in practice this can be a significant burden to the library maintainer. FWIW, I don't see any reason why a library can't use externally-defined types directly, /as long as/ they have some mechanism for ensuring ABI consistency between the two libraries (i.e., an ABI change in the underlying library is always accompanied by an soname change in the dependent library). (BTW, pkg-config upstream wrongly claims that exporting dependent libs in the pkg-config --libs output provides this protection. :/) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]