Commit Graph

9 Commits

Author SHA1 Message Date
Marius Vlad
c4076ef88a plug-ins: Migrate pipewire and remoting plug-ins headers to public header
directory

Weston is also a user of the plug-ins, so make use of it. With this
change we unconditionally install the plug-in headers even though
libweston might not be built with support for them.

Suggested-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
2020-09-04 10:36:48 +00:00
Marius Vlad
380ceee6a1 remoting, pipewire: Install pipewire and remoting plug-ins headers
Required for other users of libweston.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
2020-08-27 14:32:26 +03:00
Daniel Stone
4b8b60ebfd remoting: Use DRM FourCC formats instead of GBM formats
The remoting plugin currently has a set_gbm_format() hook, which accepts
GBM_FORMAT_* tokens from the host to set as a supported format.
GBM_FORMAT_* values are strictly aliased with DRM_FORMAT_*.

In order to avoid an extra unnecessary dependency from the remoting
plugin on GBM, switch to using the formats from libdrm instead.

This fixes a compile error seen when the remoting plugin is enabled:

    ../remoting/remoting-plugin.c:39:10: fatal error: gbm.h: No such file or directory
       39 | #include <gbm.h>
          |          ^~~~~~~
    compilation terminated.

The error was caused by not having any dependency at all on GBM from
the remoting backend, which is fixed here by adding a new dependency on
the libdrm headers for drm_fourcc.h.

Signed-off-by: Daniel Stone <daniels@collabora.com>
2019-11-11 10:54:17 +00:00
Stefan Agner
8d63e25963 remoting: make sure GL renderer is enabled
The remoting plug-in requires DRM virtual support which depends on
the GL renderer. Make sure the option is enabled.

Signed-off-by: Stefan Agner <stefan@agner.ch>
2019-10-25 14:30:40 +02:00
Pekka Paalanen
71ff95a544 build: separate deps for int and ext libweston users
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>
2019-10-24 13:29:33 +03:00
Pekka Paalanen
4f5e360180 build: simplify include_directories
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>
2019-10-04 17:14:22 +03:00
Silva Alejandro Ismael
9eb974aaaf build: Fix hint to disable remoting
If a dependency is missing, the error message should tell the build option to disable it.

Show the correct build option in the error message of the remoting plugin.

Signed-off-by: Silva Alejandro Ismael <silva.alejandro.ismael@gmail.com>
2019-06-17 11:35:54 -03:00
Pekka Paalanen
292aaf9308 meson: link remoting with glib and gobject
remoting-plugin.c calls things like g_error_free() and g_object_set(), so it
needs to link glib-2.0 and gobject-2.0 explicitly, instead of relying on
GStreamer pkg-config bringing them in.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-03-28 09:43:23 +00:00
Daniel Stone
8011b0fa03 Add Meson build system
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>
2018-12-09 14:50:54 +02:00