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>
The usage of testing tool as flatkpak is discouraged by upstream
developers, see comments from thread:
https://lists.freedesktop.org/archives/spice-devel/2019-February/047877.html
One might argue that keep this might be useful for documentation. For
that, please refer to updated documentation from Flatpak and
applications that have adopted Flatpak integration such as GNOME
Boxes.
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Marc-André Lureau <marcandre.lureau@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>
The spice-controller was a small library to let NPAPI browser plugins
communicate with the spice client. Due to usage of vala, the library
could not promise ABI stability, and was also considerer a pretty
poor implementation.
Furthermore, major browser vendors began to phase out NPAPI support in
2013, and some would like to see it gone by the end of this
year (realistically, it may not happen though).
As an alternative, remote-viewer (the first class Spice client)
learned to connect with a file of mime type application/x-virt-viewer,
as early as February 2013 with v0.5.5. I also proposed a DBus
controller, and a simpler way to pass connection details via stdin.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
To give an example for creating flatpaks depending on spice-gtk
How to build and run the flatpak:
spicy uses GNOME SDK runtime, version 3.24. The runtime provides tools
and libraries necessary to build the flatpak
$ flatpak remote-add --if-not-exists gnome https://sdk.gnome.org/gnome.flatpakrepo
$ flatpak install gnome org.gnome.Sdk//3.24
To build and run the flatpak of spicy:
$ flatpak-builder spicy data/org.spicespace.spicy.json
$ flatpak build-export repo spicy
$ flatpak --user remote-add --no-gpg-verify --if-not-exists spice-repo repo
$ flatpak --user install spice-repo org.spicespace.spicy
$ flatpak run org.spicespace.spicy
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This makes usb-redir a lot more userfriendly to use. This has been
discussed with the security team and they are ok with it, rationale:
Since we only set <allow_active> to yes, we only give raw usb access
to users *physically present behind the machine*. This is ok since
they already have full control over usb devices anyways, they can
always just unplug the device and put it in a user controlled machine.
This follows how we already grant a great deal of access to users
*physically present behind the machine* including dangerous things like
/dev/sg access for cd/dvd writers. And raw usb access to all devices which
happen to have a userspace driver rather then an in kernel driver.
Also the opening up is limited compared to the existing opening up of
other devices listed above in that:
1) It will only happen on machines which have spice-glib installed
2) We are not opening up the device nodes rights automatically, as an udev rule
would do. So there is no chance that any random app can start (accidentally)
poking the devices.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
spice-client needs to be able to open the device nodes under /dev/bus/usb
to be able to redirect a usb device to the guest. Normally opening these
nodes is only allowed by root. This patch adds a suid root helper which
asks policykit if it is ok to grant raw usb device access, and if policykit
says it is ok, opens up the acl so that the spice-client can open the device
node.
As soon as spice-client closes the stdin of the helper, the helper removes
the extra rights. This ensures that the acl gets put back to normal even if
the spice client crashes. Normally the spice-client closes stdin directly
after opening the device node.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
