#12 Compile Time Version Test Defines

closed
None
5
2012-05-23
2012-05-18
Kyle
No

Please add something like the following in rfbconfig.h:

/* What it might look like for the 0.9.8.2 release */

#define LIBVNCSERVER_VERSION_MAJOR 0.9
#define LIBVNCSERVER_VERSION_MINOR 8
#define LIBVNCSERVER_VERSION_PATCHLEVEL 2

/* What it might look like for the 0.9.9 release */

#define LIBVNCSERVER_VERSION_MAJOR 0.9
#define LIBVNCSERVER_VERSION_MINOR 9
#define LIBVNCSERVER_VERSION_PATCHLEVEL 0

That makes it possible to do things like this in code that uses libvncserver:

#if LIBVNCSERVER_VERSION_MAJOR > 0.9 || \ (LIBVNCSERVER_VERSION_MAJOR == 0.9 && \ LIBVNCSERVER_VERSION_MINOR >= 9)
/* Initialize listen6sock variable */
#endif

The way it is now, a configure compile-test is required to determine whether or not the new fields are there.

Either that or testing for the TURBO_DEFAULT_SUBSAMP macro being defined as a stand-in for IPv6-fields-in-rfbClient-struct-are-present.

The current LIBVNCSERVER_VERSION string is just not compile-time testable in this fashion.

Discussion

  • Kyle
    Kyle
    2012-05-18

    • assigned_to: nobody --> bk138
     
  • I've now done it this way to somehow accomodate the four-digit version number. What do you think?

    +# set detailed version info
    +AC_DEFINE(MAJOR_VERSION, 0, LibVNCServer major version)
    +AC_DEFINE(MINOR_VERSION, 9, LibVNCServer minor version)
    +AC_DEFINE(RELEASE_NUMBER, 10, LibVNCServer release number)
    +AC_DEFINE(SUBRELEASE_NUMBER, 0, LibVNCServer subrelease number aka patchlevel)

     
  • Kyle
    Kyle
    2012-05-21

    Excellent.

    They will have a LIBVNCSERVER (or similar) prefix on them though, right?

    +# set detailed version info
    +AC_DEFINE(LIBVNCSERVER_MAJOR_VERSION, 0, LibVNCServer major version)
    +AC_DEFINE(LIBVNCSERVER_MINOR_VERSION, 9, LibVNCServer minor version)
    +AC_DEFINE(LIBVNCSERVER_RELEASE_NUMBER, 10, LibVNCServer release number)
    +AC_DEFINE(LIBVNCSERVER_SUBRELEASE_NUMBER, 0, LibVNCServer subrelease number aka patchlevel)

     
  • I had a talk on the mailing list about our versioning, consensus was to just use a three-digit scheme, i.e. major minor patchlevel. Thus, 0.9.10 will be major 0 minor 9 patchlevel 10. Will release that version soon. Ok to close the issue from your side?

     
  • Kyle
    Kyle
    2012-05-23

    • status: open --> closed
     
  • Kyle
    Kyle
    2012-05-23

    Fixed in git fef4386accfe686abc304e43fec235eefdbacd3e

    Yup. fine to close it.