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

["Daniel P. Berrange" <berrange redhat com>]

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.

 - 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

 - 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'

 - 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


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.

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 ?

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|