The cms-static, desktop-shell, hmi-controller, ivi-shell, and screen-share
modules use symbols from libexec_weston, e.g.:
$ ldd /usr/lib/x86_64-linux-gnu/weston/desktop-shell.so | grep "not found"
libexec_weston.so.0 => not found
Loading these modules from weston happens to work because the weston executable
itself links against libexec_weston, and has an rpath set. Still, these modules
depend on a library in a non-standard location. Adding an rpath could help
static checkers to make sure all shared objects' dependencies are present.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Allow to set and get one opaque pointer. The test suite will then use this to
pass data from the test runner to the test plugin, so that the plugin can then
run what it needs to. This is useful when the test runner calls wet_main()
directly instead of forking a compositor.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
All these plugins use symbols that were exported by the weston executable and
are now exported by libexec-weston.so. Linking these to libexec-weston.so fixes
unresolved symbols.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is preparation for disallowing unresolved symbols project-wide.
This is a temporary fix that should be reverted and fixed properly later.
/usr/bin/ld: compositor/fb12c4d@@cms-colord@sha/cms-helper.c.o: in function `weston_cms_set_color_profile':
/home/pq/build/weston-meson/../../git/weston/compositor/cms-helper.c:79: undefined reference to `cmsReadTag'
/usr/bin/ld: /home/pq/build/weston-meson/../../git/weston/compositor/cms-helper.c:91: undefined reference to `cmsEvalToneCurveFloat'
/usr/bin/ld: /home/pq/build/weston-meson/../../git/weston/compositor/cms-helper.c:92: undefined reference to `cmsEvalToneCurveFloat'
/usr/bin/ld: /home/pq/build/weston-meson/../../git/weston/compositor/cms-helper.c:93: undefined reference to `cmsEvalToneCurveFloat'
/usr/bin/ld: compositor/fb12c4d@@cms-colord@sha/cms-helper.c.o: in function `weston_cms_destroy_profile':
/home/pq/build/weston-meson/../../git/weston/compositor/cms-helper.c:108: undefined reference to `cmsCloseProfile'
/usr/bin/ld: compositor/fb12c4d@@cms-colord@sha/cms-helper.c.o: in function `weston_cms_load_profile':
/home/pq/build/weston-meson/../../git/weston/compositor/cms-helper.c:131: undefined reference to `cmsOpenProfileFromFile'
See also #263
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This takes everything that was in 'weston' the executable a turns it into
library. A new trivial 'weston' executable is written.
Creating the library will allow future improvements:
- we can link weston plugins against the library, meaning that they no longer
need unresolved symbols to be allowed during linking
- tests do not have to fork() and exec() 'weston', they can just link to the
library and call wet_main() after setting things up; this will help with
using a debugger
install_rpath is set so that we can install the library into weston's module
directory, away from the normal libraries in a system. This is one library we
do not intend for others to use.
The library has no stable ABI and is not versioned.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We have two kinds of libweston users: internal and external. Weston, the
frontend, counts as an external user, and should not have access to libweston
private headers. The shell plugins are external users as well, because we
intend people to be able to write them. Renderers, backends, and some plugins
are internal users who will need access to private headers.
Create two different Meson dependency objects, one for each kind.
This makes it less likely to accidentally use a private header.
Screen-share is a Weston plugin and therefore counts as an external user, but
it needs the backend API to deliver input. Until we are comfortable exposing
public API for that purpose, let it use internal headers.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Define common_inc which includes both public_inc and the project root directory.
The project root directory will allow access to config.h and all the shared/
headers.
Replacing all custom '.', '..', '../..', '../shared' etc. include paths with
common_inc reduces clutter in the target definitions and enforces the common
#include directive style, as e.g. including shared/ headers without the
subdirectory name no longer works.
Unfortunately this does not prevent one from using private libweston headers
with the usual include pattern for public headers.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
build path ends in the final binary package causing the
build not to be reproducible byte-by-byte.
Reference:
https://bugs.debian.org/899358
Signed-off-by: Héctor Orón Martínez <zumbi@debian.org>
cms-colord.c calls things like g_string_free() and g_object_unref(), so it
needs to link glib-2.0 and gobject-2.0 explicitly, instead of relying on colord
pkg-config bringing them in.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
When building screen-share module with meson loading the module
fails with:
[00:01:28.604] Failed to load module: /usr/local/lib/weston/screen-share.so: undefined symbol: os_create_anonymous_file
Failed to process Wayland connection: Broken pipe
failed to create display: Broken pipe
The function os_create_anonymous_file is defined in libshared,
adding libshared to the dependency makes sure the function gets
compiled into screen-share.so.
Fixes: https://gitlab.freedesktop.org/wayland/weston/issues/208
Signed-off-by: Stefan Agner <stefan@agner.ch>
If xwayland is disabled, compositor/weston is built without
compositor/xwayland.c, which defines wet_load_xwayland.
compositor/fb12c4d@@weston@exe/main.c.o: In function `main':
../weston-5.0.0-169-g2d4cc4f4dd6a/compositor/main.c:3103: undefined reference to `wet_load_xwayland'
Provide an empty stub for wet_load_xwayland if xwayland is disabled.
With that we also have to remove xwayland.c from the autotools build
if xwayland is disabled, to avoid a multiple definition error.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
This is so that, for instance, people using weston as their main Wayland
compositor can invert the sense of two finger scrolling or change
pointer acceleration using weston.ini, rather than having to edit C
code.
All of the options that libinput itself exposes through its API are now
exposed in weston.ini. The new options are called `tap-and-drag`,
`tap-and-drag-lock`, `disable-while-typing`, `middle-emulation`,
`left-handed`, `rotation`, `accel-profile`, `accel-speed`,
`scroll-method`, `natural-scroll`, and `scroll-button`. I have
successfully tested everything except for `rotation`, out of a lack of
hardware support.
weston now depends directly on libevdev for turning button name strings into
kernel input codes. This was needed for the `scroll-button` config
option. (weston already depends indirectly on libevdev through
libinput, so I figured people would be OK with this.) As a practical
matter for debian-style packagers, weston now has a build dependency on
libevdev-dev.
Right now, the code applies the same options to all attached devices
that a given option is relevant for. There are plans for multiple
[libinput] sections, each with different device filters, for users who
need more control here.
Signed-off-by: Eric Toombs <3672-ewtoombs@users.noreply.gitlab.freedesktop.org>
Meson links with the C compiler, not the raw linker.
With clang+LLD, the bare flag would be ignored.
Signed-off-by: Greg V <greg@unrelenting.technology>
Meson is a build system, currently implemented in Python, with multiple
output backends, including Ninja and Make. The build file syntax is
clean and easy to read unlike autotools. In practise, configuring and
building with Meson and Ninja has been observed to be much faster than
with autotools. Also cross-building support is excellent.
More information at http://mesonbuild.com
Since moving to Meson requires some changes from users in any case, we
took this opportunity to revamp build options. Most of the build options
still exist, some have changed names or more, and a few have been
dropped. The option to choose the Cairo flavour is not implemented since
for the longest time the Cairo image backend has been the only
recommended one.
This Meson build should be fully functional and it installs everything
an all-enabled autotools build does. Installed pkg-config files have
some minor differences that should be insignificant. Building of some
developer documentation that was never installed with autotools is
missing.
It is expected that the autotools build system will be removed soon
after the next Weston release.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Co-authored-by: Pekka Paalanen <pq@iki.fi>
Signed-off-by: Pekka Paalanen <pq@iki.fi>
Philipp Zabel
Pekka Paalanen
Héctor Orón Martínez
Stefan Agner
Eric Toombs
Pekka Paalanen
Greg V
Daniel Stone