It's from Oct 2020, and widely available on various distro or backports.
Fix related meson warnings.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Supported by Meson 0.49 (required by Spice-GTK).
New syntax is shorter and is recommended in
https://mesonbuild.com/Release-notes-for-0-49-0.html
("Joining paths with /").
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
Maintaining 1 build system is hard. Maintaining 2 is even harder.
It seems the meson build system is now in good shape to replace
autotools. Like many desktop projects, let's move entirely to meson
and drop autotools support.
Known changes:
- generating changelog files in the dist tarball. This is not strictly
required, and can be added back later.
- generated files are not included in the dist tarball. In some ways,
this can be considered a good thing.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Without this commit spice-client-gtk-3.0.vapi may be built
before spice-client-glib-2.0.vapi if build_jobs > 1. This causes
the build to fail because the former depends on the latter
If gir files are not installed generate_vapi is not able to
find generated gir files, so look also in src generated files.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
In a comparison with current autotools build system, meson/ninja
provides a huge improvement in build speed, while keeping the same
functionalities currently available and being considered more user
friendly.
The new system coexists within the same repository with the current one,
so we can do more extensive testing of its functionality before deciding
if the old system can be removed, or for some reason, has to stay for
good.
- Meson: https://mesonbuild.com
This is the equivalent of autogen/configure step in autotools. It
generates the files that will be used by ninja to actually build the
source code.
The project has received lots of traction recently, with many GNOME
projects willing to move to this new build system. The following wiki
page has more details of the status of the many projects being ported:
https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting
Meson has a python-like syntax, easy to read, and the documentation
on the project is very complete, with a dedicated page on how to port
from autotools, explaining how most common use cases can be
implemented using meson.
http://mesonbuild.com/Porting-from-autotools.html
Other important sources of information:
http://mesonbuild.com/howtox.htmlhttp://mesonbuild.com/Syntax.htmlhttp://mesonbuild.com/Reference-manual.html
- Ninja: https://ninja-build.org
Ninja is the equivalent of make in an autotools setup, which actually
builds the source code. It has being used by large and complex
projects such as Google Chrome, Android and LLVM. There is not much to
say about ninja (other than it is much faster than make) because we
won't interact directly with it as much, as meson does the middle man
job here. The reasoning for creating ninja in the first place is
explained on the following post:
http://neugierig.org/software/chromium/notes/2011/02/ninja.html
Also its manual provides more in-depth information about the design
principles:
https://ninja-build.org/manual.html
- Basic workflow:
Meson package is available for most if not all distros, so, taking
Fedora as an example, we only need to run:
# dnf -y install meson ninja-build.
With Meson, building in-tree is not possible at all, so we need to
pass a directory as argument to meson where we want the build to be
done. This has the advantage of creating builds with different options
under the same parent directory, e.g.:
$ meson ./build --prefix=/usr
$ meson ./build-extra -Dextra-checks=true -Dalignment-checks=true
After configuration is done, we call ninja to actually do the build.
$ ninja -C ./build
$ ninja -C ./build install
Ninja defaults to parallel builds, and this can be changed with the -j
flag.
$ ninja -j 10 -C ./build
- Hacking:
* meson.build: Mandatory for the project root and usually found under
each directory you want something to be built.
* meson_options.txt: Options that can interfere with the result of the
build.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Not so many systems require gtk+ 2.0 these days, let's move on.
This drops the old python bindings (non-gir based), and the
unsteady/experimental gtk2-only XShm support.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Currently, building vala bindings from a tarball is broken because
spice-client-glib-2.0.deps is missing from the tarball. This commit
adds it to EXTRA_DIST and also makes sure the vala bindings don't
get built/installed unless --enable-vala has been passed to configure.
This means vala must be installed to build the vala bindings from a
tarball. Fixes fdo bug #44000.
Disable usbredir, since it wants to install file in /.
Disable vala for distcheck for 2 reasons: not needed after dist and
binding build issue.
Ship with spice-gtk-3.0 vala bindings
https://bugs.freedesktop.org/show_bug.cgi?id=44000
With the (upcoming) introduction of the usb device node acl helper, which
uses policykit, spice_usbredir_channel_connect() may take a long time as
it will be waiting for the helper, which will be waiting for policykit which
may be interacting with the user. So spice_usbredir_channel_connect() will
need to become async, and since spice_usb_device_manager_connect_device
calls spice_usbredir_channel_connect it thus also needs to become async.
Note that this patch only changes spice_usb_device_manager_connect_device's
API to use the standard GIO async API, it is not actually async after this
patch since spice_usbredir_channel_connect is not yet async.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
