Re: platform compatibility policy

[Havoc Pennington <hp redhat com>]

Excellent ideas...

Colm Smyth <Colm Smyth ireland sun com> writes: 
> First of all, I believe that source and binary compatability 
> should only be required for stable *public* interfaces.  
> 
> If an interface is wholly private to an application (e.g.  some
> functions in a library that are shared by two closely related
> programs, where those functions will never be needed elsewhere in
> GNOME), then there is no need to maintain compatability over
> releases.

We need to be careful here. While some interfaces are genuinely
private and enforced, others are theoretically private but in reality
people are using them. (By "enforced" I mean for example that we don't
install the header file.)
 
> It would be really useful to attempt to capture GNOME's public
> interfaces in a document, or (even better) a database. At
> a high level, this should indicate the stability level of
> each GNOME interface perhaps using names like stable, evolving,
> unstable, obsolete, and standard to indicate how long that
> interface will offer binary compatbility for any (client)
> applications that use the interface.
> 
> Examples of these classifications would include:
> 
> - glib 2.0 - stable
> - glib 1.3.1 - unstable
> - libgnorba - obsolete
> - libxml, libwww - standard (a public interface that the GNOME
>   Foundation does not own)

Nice idea. 
 
> It's possible to automatically validate an application
> by checking that there are only references to public
> symbols. By statically analyzing the dependent libraries
> of an application, it's possible to find all symbols that
> are defined within the application code and all symbols
> that are imported from public interfaces in GNOME libraries.
> Any symbol that is resolved from a GNOME library that is
> not part of a public interface can be highlighted as
> a binary compatibility violation.
> 
> Actually this is exactly that a Solaris ABI validation tool
> called AppCert does. The hardest part is actually capturing
> all of the symbols that are part of the public interface
> of each library, although this too can be automated by
> taking the syntax-checking parts of a C compiler and
> outputting all symbols defined within the public header files
> of a library into a 'database' file for that public interface.
> 
> If there is any interest in such a tool for GNOME, I can contact
> the team at Sun responsible for AppCert to see if they
> could contribute the AppCert tool-set to open-source
> for use in the GNOME project.
> 

It sounds useful, I think we'd be interested. 

For GTK 2.0, another thing we're doing is renaming all the private
entry points with an underscore in front, and then we'll tell the
linker not to export those from the library (on linkers that support
that). This doesn't catch all private entry points, such as private
functions exported by GDK for use in GTK, but it does catch a lot of
them.

Havoc

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers