Danek Duvall wrote:
> I'll echo Jim's comments in the SQLite case about calling everything
> Volatile. It's really not appropriate, especially since these are
> components that exist specifically for other projects to build on top of.
>
I take your point about not to throw "Volatile" at everything even the
older taxonomy
basically said everything External is now named 'Volatile' as according
to this document,
http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy
We could classify these libraries to be
Uncommitted (which meant Evolving in the older taxonomy, not the Unstable)
for gtkmm, glibmm and cairomm, though we would still keep sigc++ to be
Volatile
given that it is only a fairly recent addition to the desktop stack.
Even though it may sound confusion (Uncommitted sounds as bad as Volatile).
> 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.
> Can you provide some rationale for why you expect these interfaces would
> need to change incompatibly and without warning in patches? Or, better,
> why they're actually highly unlikely to change incompatibly at all, and
> thus could be Committed? :)
>
> You're also specifying everything by pathname, which is inappropriate. For
> instance, the .pc files and the directory they live in are Private
> implementation details, but the base name of the files are the public
> interfaces that people will use to pass to pkg-config(1). That's how they
> should be described.
>
>
>> /usr/lib/libsigc-2.0.so Volatile
>> /usr/lib/libcairomm-1.0.so Volatile
>> /usr/lib/libglibmm-2.4.so Volatile
>>
>> /usr/liblibatkmm-1.6.so Volatile
>> /usr/lib/libgtkmm-2.4.so Volatile
>> /usr/lib/libgdkmm-2.4.so Volatile
>> /usr/lib/libpangomm-1.4.so Volatile
>>
>
> 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.
> Do they have their private symbols properly scoped?
>
Based on the current implementation, they are not.
>
>> /usr/lib/libglibmm_generate_extra_defs-2.4.so Volatile
>>
>
> Does anyone ever need to link to this library specifically? This seems
> like a very private implementation detail that should either be a filter
> library or simply not exist on Solaris.
>
>
>> /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.
>> /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.
>
>> /usr/include/sigc++-2.0 Volatile
>> Directory for hearder files
>> /usr/include/cairomm-1.0 Volatile
>> Directory for header files
>> /usr/include/glibmm-2.4/glibmm Volatile
>> Header files directory
>>
This one must have. It contains all the header fiels for glibmm
>> /usr/include/glibmm-2.4/glibmm_generate_extra_defs Volatile
>> Header files directory
>>
>
> These two directories seem rather private, too.
>
This one can possibly removed from interface table. It doesn't seems
to do much at the moment.
>
>> /usr/include/atkmm-1.6 Volatile
>> Directory for atkmm headfiles
>> /usr/include/gtkmm-2.4 Volatile
>> Directory for pangomm headfiles
>> /usr/include/pangomm-1.4 Volatile
>> Directory for gdkmm headfiles
>> /usr/demo/jds/bin/gtkmm-demo Volatile
>>
>
> Here's a general question to the JDS folks -- is it worth making any of
> these header directories Public at all? It seems that pretty much the only
> way people know where these things are is through pkg-config(1). Or are
> these names, complete with version numbers, stable enough that it's what
> people actually code to?
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?
> 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.
Thanks,
-Ghee
> Danek
>
