Re: [gtk-vnc-devel] [patch] versions
- From: Anthony Liguori <anthony codemonkey ws>
- To: "Daniel P. Berrange" <berrange redhat com>
- Cc: gtk-vnc-devel List <gtk-vnc-devel lists sourceforge net>
- Subject: Re: [gtk-vnc-devel] [patch] versions
- Date: Sun, 20 Jan 2008 15:37:04 -0600
Daniel P. Berrange wrote:
On Sun, Jan 20, 2008 at 02:02:04PM -0300, Jonh Wendell wrote:
Due to vinagre get into GNOME 2.22 Desktop, I need to be more careful
when using gtk-vnc trunk.
For example, I'm using the new function
vnc_display_set_lossy_encoding(), available only in trunk. This has
caused some issues on people trying to build vinagre from trunk.
In order to fix this, I created a file vncversion.h.in, similar to
gtkversion.h.in, which we can test if we're compiling against a specific
version of gtk-vnc.
In this case, I could just put in vinagre:
#if VNC_CHECK_VERSION(0, 3, 3)
vnc_display_set_lossy_encoding (VNC_DISPLAY(tab->priv->vnc), TRUE);
What do you think about this approach? OK to commit? comments?
Doing checks based on version numbers is a really bad idea IMHO. The
better approach is to check for the actual function in autoconf.
I agree. An autoconf check is definitely the right thing to do.
eg in your configure.in add
Then in your code you'll be able todo
NB, make sure you include 'config.h' in all your files
Alternatively don't make use of new symbols from unreleased GTK-VNC
code in the trunk for vinagre. Keep it on a branch off the trunk until
the GTK-VNC release is done - since we release once a month this isn't
too much hassle - and it saves cluttering up the vinagre code with lots
of #if blocks.
Yes, I agree. Until a symbol appears in a release, we can't guarantee
that it's signature will not change or that it won't disappear altogether.
] [Thread Prev