From: Emil Velikov <emil.veli...@collabora.com> Provides some ease wrt constructing the required version.
Cc: Quentin Glidic <sardemff7+...@sardemff7.net> Suggested-by: Quentin Glidic <sardemff7+...@sardemff7.net> Signed-off-by: Emil Velikov <emil.veli...@collabora.com> --- I've swapped ENCODE with API since it makes comparisons a lot better and it implies a full version including PATCH/MICRO. Yes, GTK/GDK does not have have it yet every project that has ENCODE macro on my system: cairo, pango, nm and json-glib does. Perhaps I have the wrong software installed for my grep search ;-) #if REQUIRED_foo >= foo(x,y) Can bring ENCODE back if people miss it. Having a look at the file... - wasn't the file meant to be installed alongside the weston binary, since the latter exports symbols like Xorg and binaries depend on those. - alternatively should we just rename the defines to LIBWESTON_VERS... Personally I'm leaning that the following might be a good idea: - move all the exports to libweston, make the compositor(s) expose as little symbols as possible. there's a few left in weston atm. - use LIBWESTON_VERSION... unless there's (m)any open-source users that depend on the WESTON_VERSION... macros. I don't have a strong preference on the route taken, just some ideas. -Emil --- README | 16 +++++++++------- libweston/version.h.in | 2 ++ 2 files changed, 11 insertions(+), 7 deletions(-) diff --git a/README b/README index 37090d5..d0c8a64 100644 --- a/README +++ b/README @@ -96,13 +96,14 @@ version check, default to visible/hidden old/new symbols and so on. libweston aims to guard all newly introduced API, in order to prevent subtle breaks that a simple recompile (against a newer version) might cause. -The macro is of the format 0x$MAJOR$MINOR and does not include PATCH version. -As mentioned in the Versioning scheme section, the latter does not reflect any -user visible API changes, thus should be not considered part of the API version. +The macro must be compared against LIBWESTON_API_VERSION($MAJOR, $MINOR) and +does not include PATCH version. As mentioned in the Versioning scheme section, +PATCH does not reflect any user visible API changes, thus should be not +considered part of the API version. All new symbols should be guarded by the macro like the example given below: -#if REQUIRE_LIBWESTON_API_VERSION >= 0x0101 +#if REQUIRE_LIBWESTON_API_VERSION >= LIBWESTON_API_VERSION(1,1) bool weston_ham_sandwich(void); @@ -113,10 +114,11 @@ In order to use the said symbol, the one will have a similar code in their configure.ac: PKG_CHECK_MODULES(LIBWAYLAND, [libwayland-1 >= 1.1]) -AC_DEFINE(REQUIRE_LIBWESTON_API_VERSION, [0x0101]) +AC_DEFINE(REQUIRE_LIBWESTON_API_VERSION, [LIBWESTON_API_VERSION(1,1)]) -If the user is _not_ interested in forward compatibility, they can use 0xffff -or similar high value. Yet doing so is not recommended. +If the user is _not_ interested in forward compatibility, they can use high +value for MAJOR/MINOR - LIBWESTON_API_VERSION(99,99) or alike. Yet doing so is +not recommended. Libweston design goals diff --git a/libweston/version.h.in b/libweston/version.h.in index b2379d0..892c5c4 100644 --- a/libweston/version.h.in +++ b/libweston/version.h.in @@ -26,6 +26,8 @@ #ifndef WESTON_VERSION_H #define WESTON_VERSION_H +#define LIBWESTON_API_VERSION(major,minor) ((major) << 16 | (minor) << 8) + #define WESTON_VERSION_MAJOR @WESTON_VERSION_MAJOR@ #define WESTON_VERSION_MINOR @WESTON_VERSION_MINOR@ #define WESTON_VERSION_MICRO @WESTON_VERSION_MICRO@ -- 2.9.0 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
