Exposay was done as a showcase for what we could do with Weston and an
efficient compositing pipeline. This was mostly with the old
vendor-specific Raspberry Pi backend which could actually process that
many surfaces bypassing the GPU.
Given enough bitrot, Exposay is now pretty exemplary as what _not_ to do
in a Weston shell - particularly the way it manipulates existing
weston_views rather than create its own non-destructive stack.
As it's annoying technical debt, a terrible example to others, and not a
very compelling showcase in 2022, just delete it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
shell-utils contains a number of helpers which are currently in use by
both desktop-shell and kiosk-shell. In order to extend this use to
fullscreen-shell as well (which can benefit from reusing the
weston_curtain infrastructure to be able to create solid-colour views
which may or may not be opaque, as well as one function within
fullscreen-shell which was copied wholesale to shell-utils), we need to
create a separate Meson dependency object, and avoid the existing
pattern of including the source from shared/ within the source list for
each shell.
This requires creating a new top-level directory for these shared helper
functions which are required by each shell, but are not part of
libweston in and of itself.
shell-utils depends on libweston-desktop; libweston-desktop depends on
libweston; libweston depends on shared.
Thus it is not possible to expose a dependency object from the shared/
directory which declares a dependency on the libweston-desktop
dependency, as Meson processes directories in order and resolves
variable references as they are parsed.
In order to break this deadlock, this commit creates a new top-level
directory called 'shell-utils' containing only this file, which can be
parsed by Meson after libweston-desktop (making the libweston-desktop
Meson dependency variable available to the build file to declare a
dependency on that), but before the shells (making the new Meson
depenendency object available to each shell which wishes to use it).
This commit contains no functional changes to any observable code.
Signed-off-by: Daniel Stone <daniels@collabora.com>
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>
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>
In the future libweston will stop providing it for its users, since it's not
part of libweston API.
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>
Do not build matrix.c into the shell plugins. The matrix functions are exported
by libweston.so and the shell plugins links to it.
Found by inspection.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
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>
