[PATCH weston 1/2] libweston: introduce LIBWESTON_API_VERSION macro

[Emil Velikov]

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
by Weston.

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.
>
Great !

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)
 - stay
 - can be hidden.

Thanks
Emil