mainnika
/
weston
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
6498 Commits
1 Branch
0 Tags
14 MiB
Tag: Branch: Tree: c04188e546
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'c04188e546'
${ noResults }
weston/protocol/meson.build

77 lines
2.4 KiB
Raw Normal View History Unescape

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>
8 years ago
dep_scanner = dependency('wayland-scanner', native: true)
prog_scanner = find_program(dep_scanner.get_pkgconfig_variable('wayland_scanner'))
libweston: Introduce zwp_linux_explicit_synchronization_v1 Introduce support for the zwp_linux_explicit_synchronization_unstable_v1 protocol with an implementation of the zwp_linux_explicit_synchronization_v1 interface. Explicit synchronization provides a more versatile notification mechanism for buffer readiness and availability, and can be used to improve efficiency by integrating with related functionality in display and graphics APIs. In addition, the per-commit nature of the release events provided by this protocol potentially offers a solution to a deficiency of the wl_buffer.release event (see https://gitlab.freedesktop.org/wayland/wayland/issues/46). Support for this protocol depends on the capabilities of the backend, so we don't register it by default but provide a function which each backend will need to call. In this commit only the headless backend when using the noop renderer supports this to enable testing. Note that the zwp_surface_synchronization_v1 interface, which contains the core functionality of the protocol, is not implemented in this commit. Support for it will be added in future commits. Changes in v7: - Added some information in the commit message about the benefits of the explicit sync protocol. Changes in v6: - Fall back to advertising minor version 1 of the explicit sync protocol, although we support minor version 2 features, until the new wayland-protocols version is released. Changes in v5: - Meson support. - Advertise minor version 2 of the explicit sync protocol. Changes in v4: - Enable explicit sync support in the headless backend for all renderers. Changes in v3: - Use wl_resource_get_version() instead of hardcoding version 1. - Use updated protocol interface names. - Use correct format specifier for resource id. - Change test name to 'linux-explicit-synchronization.weston' (s/_/-/g). Changes in v2: - Move implementation to separate file so protocol can be registered on demand by backends. - Register protocol in headless+noop backend for testing purposes. Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
6 years ago
# XXX: For minor version 2 of zwp_linux_explicit_synchronization_v1, we
# actually need a development version after 1.17, but there is no way to
# express such a requirement at the moment.
dep_wp = dependency('wayland-protocols', version: '>= 1.17')
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>
8 years ago
dir_wp_base = dep_wp.get_pkgconfig_variable('pkgdatadir')
install_data(
[
'weston-debug.xml',
],
install_dir: join_paths(dir_data, dir_protocol_libweston)
)
generated_protocols = [
[ 'input-method', 'v1' ],
[ 'input-timestamps', 'v1' ],
[ 'ivi-application', 'internal' ],
[ 'ivi-hmi-controller', 'internal' ],
[ 'fullscreen-shell', 'v1' ],
[ 'linux-dmabuf', 'v1' ],
libweston: Introduce zwp_linux_explicit_synchronization_v1 Introduce support for the zwp_linux_explicit_synchronization_unstable_v1 protocol with an implementation of the zwp_linux_explicit_synchronization_v1 interface. Explicit synchronization provides a more versatile notification mechanism for buffer readiness and availability, and can be used to improve efficiency by integrating with related functionality in display and graphics APIs. In addition, the per-commit nature of the release events provided by this protocol potentially offers a solution to a deficiency of the wl_buffer.release event (see https://gitlab.freedesktop.org/wayland/wayland/issues/46). Support for this protocol depends on the capabilities of the backend, so we don't register it by default but provide a function which each backend will need to call. In this commit only the headless backend when using the noop renderer supports this to enable testing. Note that the zwp_surface_synchronization_v1 interface, which contains the core functionality of the protocol, is not implemented in this commit. Support for it will be added in future commits. Changes in v7: - Added some information in the commit message about the benefits of the explicit sync protocol. Changes in v6: - Fall back to advertising minor version 1 of the explicit sync protocol, although we support minor version 2 features, until the new wayland-protocols version is released. Changes in v5: - Meson support. - Advertise minor version 2 of the explicit sync protocol. Changes in v4: - Enable explicit sync support in the headless backend for all renderers. Changes in v3: - Use wl_resource_get_version() instead of hardcoding version 1. - Use updated protocol interface names. - Use correct format specifier for resource id. - Change test name to 'linux-explicit-synchronization.weston' (s/_/-/g). Changes in v2: - Move implementation to separate file so protocol can be registered on demand by backends. - Register protocol in headless+noop backend for testing purposes. Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
6 years ago
[ 'linux-explicit-synchronization', 'v1' ],
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>
8 years ago
[ 'presentation-time', 'stable' ],
[ 'pointer-constraints', 'v1' ],
[ 'relative-pointer', 'v1' ],
[ 'tablet', 'v2' ],
[ 'text-cursor-position', 'internal' ],
[ 'text-input', 'v1' ],
[ 'viewporter', 'stable' ],
[ 'weston-debug', 'internal' ],
[ 'weston-desktop-shell', 'internal' ],
[ 'weston-screenshooter', 'internal' ],
[ 'weston-test', 'internal' ],
[ 'weston-touch-calibration', 'internal' ],
[ 'xdg-output', 'v1' ],
[ 'xdg-shell', 'v6' ],
]
foreach proto: generated_protocols
proto_name = proto[0]
if proto[1] == 'internal'
base_file = proto_name
xml_path = '@0@.xml'.format(proto_name)
elif proto[1] == 'stable'
base_file = proto_name
xml_path = '@0@/stable/@1@/@1@.xml'.format(dir_wp_base, base_file)
else
base_file = '@0@-unstable-@1@'.format(proto_name, proto[1])
xml_path = '@0@/unstable/@1@/@2@.xml'.format(dir_wp_base, proto_name, base_file)
endif
foreach output_type: [ 'client-header', 'server-header', 'private-code' ]
if output_type == 'client-header'
output_file = '@0@-client-protocol.h'.format(base_file)
elif output_type == 'server-header'
output_file = '@0@-server-protocol.h'.format(base_file)
else
output_file = '@0@-protocol.c'.format(base_file)
if dep_scanner.version().version_compare('< 1.14.91')
output_type = 'code'
endif
endif
var_name = output_file.underscorify()
target = custom_target(
'@0@ @1@'.format(base_file, output_type),
command: [ prog_scanner, output_type, '@INPUT@', '@OUTPUT@' ],
input: xml_path,
output: output_file,
)
set_variable(var_name, target)
endforeach
endforeach