Re: [gtk-vnc-devel] Added RPM packaging & make python build optional

[Anthony Liguori <anthony codemonkey ws>]

Daniel P. Berrange wrote:
> Since we're intending to make use of GTK-VNC in virt-manager for Fedora 8
> I need to get GTK-VNC ready for inclusion in Fedora 8 too. This means
> sorting out the library build process. So I've code a changeset which does
>
>  - Use automake/conf/libtool instead of distutils because once you step
>    outside distuils tiny world view you end up having to wrie bucket
>    loads of python todo what you want. automake is not pretty, but it
>    works well & is widely understood.
>   

I'm not a huge fan of autotools but you are correct that distutils can 
become a pain.  I'm okay with this change.

>  - Create a libgtk-vnc-1.0.so  shared library. It is common practice with
>    GTK related projects to include the major version in the library name
>    so if you need to break ABI, then you can still install multiple versions
>    side-by-side very easily
>   

Thanks, this was sorely needed.

>  - Install vncdisplay.h into /usr/include/gtk-vnc-1.0/vncdisplay.h again
>    using version dir for same reason as above
>
>  - Rename the python module to be 'gtkvnc'
>   

This is a good time to perhaps pick a better name?  We aren't really an 
official GTK project so I don't know if this is really proper.   Any 
thoughts?

>  - Added a RPM spec file gtk-vnc.spec to create gtk-vnc, gtk-vnc-devel
>    and gtk-vnc-python
>
>  - Added a autobuild.sh script which I'll use to do automated nightly
>    builds
>
>  - Added a linker script libgtk-vnc_sym.version to ensure that only the
>    symbols from vncdispay.h are exported in the ELF library - all the
>    rest are marked private by the linker
>
>  - Added a pkg-config script to /usr/lib/pkgconfig/gtk-vnc-1.0.pc for use
>    by apps which want to build against gtk-vnc C library
>   

All this looks good.

> My thoughts on library ABI, are that we should reserve the right to break
> it at will in the short term - basically until we've got Vinagre and
> Virt Manager successfully using its API - those two apps shold be good
> sanity tests for the API. Then we should follow a 'new APIs only' approach
> so we maintain back compat.  If we find we absolutely need to break API
> then we can switch to gtk-vnc-2.0  and so on. Hopefully this won't be
> neccessary though.
>   

This seems like a good strategy to me.

> The changeset is in my staging tree here:
>
> http://hg.berrange.com/libraries/gtk-vnc--devel?cs=bf5526cf5160
>
> Any objections to pushing it to the main repo ?
>   

I don't object to it.  I'm on travel/vacation for the next two weeks so 
I won't get to really look at it until I get back.

Regards,

Anthony Liguori

> Regards,
> Dan.
>