Weston exported symbols

[Pekka Paalanen]

On Wed, 17 Aug 2016 13:14:22 +0100
Emil Velikov <emil.l.velikov at gmail.com> wrote:

> 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) ?

Giulio, maybe you can solve the naming stalemate? :-)

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

Ok, do we need to make a difference between Weston version.h and
libweston version.h?

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

$ nm -CD --defined-only .libs/weston
0000000000409a00 R _IO_stdin_used
000000000060e458 B __bss_start
000000000060e438 D __data_start
00000000004099f0 T __libc_csu_fini
0000000000409990 T __libc_csu_init
000000000060e458 D _edata
000000000060e638 B _end
00000000004099f4 T _fini
0000000000402fd0 T _init
0000000000405b70 T _start

Std stuff above I believe.

000000000060e438 W data_start

What's this?

0000000000406e00 T screenshooter_create

This probably shouldn't be exported.

000000000060e600 B stderr

Std.

0000000000407fd0 T text_backend_destroy
0000000000408000 T text_backend_init

These maybe shouldn't be exported... oh wait, maybe they are used by
the shells? Maybe they should be built into the shell modules?

00000000004063f0 T weston_client_launch
00000000004065f0 T weston_client_start
0000000000408b80 T weston_config_get_libexec_dir
0000000000408610 T weston_config_get_section
0000000000408ad0 T weston_config_section_get_bool
0000000000408880 T weston_config_section_get_color
00000000004089c0 T weston_config_section_get_double
00000000004086a0 T weston_config_section_get_int
0000000000408a70 T weston_config_section_get_string
00000000004087a0 T weston_config_section_get_uint
0000000000406660 T wet_get_config
0000000000406950 T weston_parse_transform
0000000000406ba0 T weston_transform_to_string
00000000004065e0 T weston_watch_process

These might be used by weston (not libweston) plugins, seem fine to
export.

0000000000406680 T wet_load_module

Not quite sure if Weston plugins should have access... maybe they do.
Ivi-shell?


000000000060e500 B weston_screenshooter_interface
000000000060e480 B wl_keyboard_interface
000000000060e580 B zwp_input_method_context_v1_interface
000000000060e540 B zwp_input_method_v1_interface
000000000060e5c0 B zwp_text_input_manager_v1_interface
000000000060e4c0 B zwp_text_input_v1_interface

The interfaces probably shouldn't be exported, but they come from
wayland-scanner, and libwayland-{client,server} needs to exported the
wayland.xml interfaces, so it's a bit complicated to fix I suppose.

Wait... what does wl_keyboard_interface do there?? That should be from
libwayland-server.


I don't see anything that should be moved into libweston, so that side
looks clean.

Ideally weston the executable wouldn't export anything so we could build
plugins with unresolved symbols causing build-time errors, but I don't
know how to do that. Or maybe fake exports somehow during plugin builds
to just get the errors. Weak symbols with implementation "abort()" plus
some testing machinery to ensure the symbol sets stay in sync?


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160818/953645c4/attachment.sig>