For symmetry with the boolean options. I really do not want to care
whether an option is a tristate if I'm trying to set it explicitly.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
String arguments as elements in the array passed to the link_with
argument in meson's executable() functions are not valid and will end up
causing the build file generation to file. This actually ended up
exposing a bug in meson that caused it not to report where in the
meson.build file it was failing:
https://github.com/mesonbuild/meson/pull/2527
The proper way to have a variable that can contain either an empty link
target or an actual link target is:
some_target = []
if some_cond
some_target = static_library(...)
endif
This way if some_cond is False, some_target gets set to [], gets passed
to executable() in the link_with array, and then gets removed by array
flattening.
This also unbreaks Xwayland builds with -Dglx=false, the thing that
originally made me notice this.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Jon Turney <jon.turney@dronecode.org.uk>
For the loadable modules it makes sense to build for PE/COFF targets, link
those loadable modules with the import library for the Xorg executable, so
that symbols provided by the executable can be satisfied at link time (as
required by PE/COFF).
Since this uses the syntax of using the returned build target object from an
executable() with an implib: kwarg to link_with:, introduced in meson 0.42
and a syntax error with older meson, also update the minimum meson version
which we require in project() to that.
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Now that we can actually configure all of the directories xkb uses for
finding things, we can (finally, but only with meson) finally make it so
that with the correct meson configuration the Xserver will "just work"
without any additional changes to the installation prefix after
building.
For the people like me who have since scripted this part out of their
build process and forgotten about it, building and installing the X
server into a non-standard prefix has always required the following (or
something else that makes sure that X has a valid xkbcomp configuration)
commands be run right after doing the installation:
# start in root of prefix you installed X to
mkdir -pv share/X11/xkb/rules
ln -s /usr/share/X11/xkb/rules/evdev share/X11/xkb/rules/
rm -f bin/xkbcomp
ln -s /usr/bin/xkbcomp bin/
The one last piece of getting rid of this post-install junk is making
sure that we can control the directory that X uses for finding the
xkbcomp binary from meson so we can point it at the system provided
xkbcomp (/usr/bin/xkbcomp or similar). So, this patch adds a
configuration option for controlling this called xkb_bin_dir.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Well, almost all of them. No -Wdeclaration-after-statement because
that's legal in C99, and in the limited ways we use it, more readable.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
We don't really require all of C99, but enough that it's not worth
bothering with the distinction, especially if your toolchain is new
enough that meson is a thing for you. We could do strict C99 if we
really insisted on spelling it __typeof__, but who wants that? Nobody,
that's who.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
We can check the version on an existing dependency, rather than spinning
up pkg-config again just to check the right version.
Signed-off-by: Daniel Stone <daniels@collabora.com>
The Xvfb tests are passing and Xephyr-glamor is failing for me, but it
fails identically on autotools. It's disabled on Travis for now
because the >10 minutes of silence during testing times out the entire
build.
v2: Fix the disable on travis.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The version detect was erroring out with 1.9 protos installed, and we
weren't building the new code.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The keyboard grabbing protocol for Xwayland is included in
wayland-protocol 1.9.
Update the wayland-protocol required version in both configure and meson
builds and add support for this new protocol in Xwayland.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Don't build them on platforms where they aren't meaningful.
Note that autoconf defines WITH_VGAHW when building the VGAHW module, but
that doesn't seem to be used anywhere, so we just drop that.
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Eric Anholt <eric@anholt.net>
This needs a meson with PRs #1784, #1792 and #1794
Future work: remove conditionals which are always on, and simplify redundant
CYGDEBUG conditionals
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Eric Anholt <eric@anholt.net>
Using the meson idiom of initializing a variaible to an empty array to
represent a null value does not work well for a variable expected to hold a
dependency object, as trying to apply found() to it will fail (currently).
I think this can be demonstrated by configuing with Dglamor=no, then gbm_dep
is set to [] in meson.build, and then tested with found() in
include/meson.build.
Use dependency('') to create an empty dependency.
Future work: In the autotools build GBM is required if build_xorg &
build_glamor. I suspect that it was also required for build_xwayland &
build_glamor, but that was never checked. That test seems to have gone
missing in meson.build, the required:false when checking for gbm should
possibly be dropped?
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Eric Anholt <eric@anholt.net>
As in autotools build, only turn on build_dbus (build dbus-core.c) if it's
needed by build_hal or build_systemd_logind, not just because dbus is
available.
Building dbus-core.c without NEED_DBUS defined fails, as the contents of
dbus-core.h are turned off.
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Acked-by: Eric Anholt <eric@anholt.net>
Add options for DRI{1,2,3}
shmfence is required for DRI3
libdrm is required for any DRI{1,2,3}
Consolidate calls to dependency('libdrm')
Set WITH_LIBDRM when building with libdrm
v2:
Initialize libxserver_dri3 to []
Manually flatten libxserver, since meson doesn't (currently)
Use version_compare rather than circumloctions with dependency()
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Eric Anholt <eric@anholt.net>
This dependency is never used, and build_dga is hardwired to false later on,
anyhow.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <ping.cheng@wacom.com>
"bulid" isn't valid anything, and build_xwayland was already defined
above.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This is a work in progress that builds Xvfb, Xephyr, Xwayland, Xnest,
and Xdmx so far. The outline of Xquartz/Xwin support is in tree, but
hasn't been built yet. The unit tests are also not done.
The intent is to build this as a complete replacement for the
autotools system, then eventually replace autotools. meson is faster
to generate the build, faster to run the bulid, shorter to write the
build files in, and less error-prone than autotools.
v2: Fix indentation nits, move version declaration to project(), use
existing meson_options for version-config.h's vendor name/web.
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
