[PATCH weston 1/2] libweston: introduce LIBWESTON_API_VERSION macro
emil.l.velikov at gmail.com
Wed Aug 17 12:14:22 UTC 2016
On 15 August 2016 at 17:16, Quentin Glidic
<sardemff7+wayland at sardemff7.net> wrote:
> On 15/08/2016 17:31, Emil Velikov wrote:
>> From: Emil Velikov <emil.velikov at collabora.com>
>> Provides some ease wrt constructing the required version.
>> Cc: Quentin Glidic <sardemff7+git at sardemff7.net>
>> Suggested-by: Quentin Glidic <sardemff7+git at sardemff7.net>
>> Signed-off-by: Emil Velikov <emil.velikov at 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.
> SOMETHING_VERSION is often a macro defined to the actual installed version,
> while SOMETHING_ENCODE_VERSION clearly brings the meaning of its purpose.
The user says "I want LIBWESTON_*API_*VERSION x,y" by using the macro.
The macro is _not_ meant to be read by users.
Users check LIBWESTON_VERSION which includes MINOR/PATCH that can be
used as needed.
Should we can add this somewhere in the documentation/readme(s) ?
>> 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.
> Which binaries depend on it?
Not "it" but "those". Let me elaborate:
The file version.h is used to build (out of tree?) weston modules X
and Y. The latter of which depend at runtime on the symbols exported
And now the not so obvious question:
Are there (m)any out of tree modules that use weston's version.h and
that one cares about ?
If there's none one can cleanup the defines as mentioned below.
>> - 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.
> I think it is fine for Weston-specific modules to use Weston-specific
> functions exported by Weston. But the less exported by Weston the better.
Can anyone skim through the list (nm -CD --defined-only is the one I
use) and mention which symbols
- should be moved (even if it's impossible atm) to libweston (or other)
- can be hidden.
More information about the wayland-devel