On Tue, Feb 05, 2008 at 04:42:19PM +0000, Ghee Teo wrote: >> Given that these libraries are themselves built on top of the C versions >> of the same libraries to which we're assigning a "Committed" label, I'd >> expect that these were at least Uncommitted, if not Committed. > > Uncommitted for gtkmm, glibmm and cairomm.
Okay. >> Are these libraries correctly versioned as described in the libraries best >> practices document? > These libraries versioned are created by the maintainer of the software. > For example, even if the version of glib that we built the sample on is > 2.14.x, it still produces the version library of libglibmm-2.4. So we > can't change these without the risk of being incompatable. I'm talking about the internal versioning and scoping that should be done for all libraries delivered on Solaris. This helps a great deal when different symbols in a library have different stability levels -- you can make symbols completely private to the library, or you can stick them in buckets which are advertised as public, or private, but usable with caution. Doing this work isn't very difficult either to do or to maintain, but upstream might be happy to accept the finished work. It looks like even the main gtk library isn't versioned, though, so I doubt it'll happen for this, either. >>> /usr/lib/glibmm-2.4/proc/gmmproc Volatile >> >> What goes here and why is it Public? > > Simon answered this as to why he want this to be public. If it is public, > it should be moved to /usr/bin I would think. Agreed. >>> /usr/lib/glibmm-2.4/include/glibmmconfig.h Volatile >>> /usr/lib/sigc++-2.0/include/sigc++config.h Volatile >>> >> >> Why do we have Public header files under /usr/lib? Such things tend to be >> Private. > > The above two header files will not be delivered, they are private, > required only to build the libraries. Okay, good. >>> /usr/include/glibmm-2.4/glibmm Volatile >>> Header files directory >>> > This one must have. It contains all the header fiels for glibmm Sure, but why are they in a subdirectory of glibmm-2.4? None of the other include directories are like that. >>> /usr/include/glibmm-2.4/glibmm_generate_extra_defs Volatile >>> Header files directory > > This one can possibly removed from interface table. It doesn't seems to > do much at the moment. Okay. > Given the rather expanded range of version number across the various > modules, I think using pkg-config(1) is definitely the recommended way of > accessing these headers directories. Do you recommend we remove all the > directories from the interface table and rely on the stability of .pc > files to access these path? It's not my recommendation to make. I'm asking *you*. >> For that matter, are the version numbers of the >> .pc files stable at all? > > Yes. I believe so. The version number are also part of the name of the > .pc file. For example, glibmm-2.4.pc is the one for glibmm. Okay. Thanks, Danek
