mirror of
https://gitlab.uni-freiburg.de/opensourcevdi/spice
synced 2025-12-26 22:48:19 +00:00
495d1612c4
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.html http://mesonbuild.com/Syntax.html http://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> Signed-off-by: Christophe Fergeau <cfergeau@redhat.com> Signed-off-by: Frediano Ziglio <fziglio@redhat.com> Acked-by: Frediano Ziglio <fziglio@redhat.com> Acked-by: Victor Toso <victortoso@redhat.com> |
||
|---|---|---|
| build-aux | ||
| docs | ||
| m4 | ||
| server | ||
| subprojects | ||
| tests | ||
| tools | ||
| uncrustify_cfg | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .gitmodules | ||
| .mailmap | ||
| .travis.yml | ||
| AUTHORS | ||
| autogen.sh | ||
| cfg.mk | ||
| ChangeLog | ||
| configure.ac | ||
| COPYING | ||
| GNUmakefile | ||
| maint.mk | ||
| Makefile.am | ||
| meson_options.txt | ||
| meson.build | ||
| NEWS | ||
| README | ||
| spice-server.pc.in | ||
| TODO.multiclient | ||
SPICE: Simple Protocol for Independent Computing Environments
=============================================================
SPICE is a remote display system built for virtual environments which
allows you to view a computing 'desktop' environment not only on the
machine where it is running, but from anywhere on the Internet and
from a wide variety of machine architectures.
Installation
------------
The SPICE package uses GNU autotools, so the build install process
follows the standard process documented in the INSTALL file. As a
quick start you can do
./configure --prefix=/usr --sysconfdir=/etc \
--localstatedir=/var --libdir=/usr/lib
make
sudo make install
Or to install into a private user specific location
./configure --prefix=$HOME/spice
make
make install
The following mandatory dependencies are required in order to
build SPICE
Spice protocol >= 0.12.14
Pixman >= 0.17.7
OpenSSL
libjpeg
zlib
The following optional dependencies increase the available
functionality
Cyrus-SASL
libcacard >= 0.1.2 (Smartcard support)
Opus >= 1.0.0 (Opus audio encoding support)
LZ4 (LZ4 compression support)
GStreamer >= 1.0.0
Communication
-------------
To communicate with the development team, or to post patches
there is a technical mailing list:
http://lists.freedesktop.org/mailman/listinfo/spice-devel
There is also a mailing list for new release announcements:
http://lists.freedesktop.org/archives/spice-announce/
To view known bugs, or report new bugs, in SPICE visit
https://gitlab.freedesktop.org/spice/spice/issues/new?
Bugs found when using an OS distribution's binary packages should
be reported to the OS vendors' own bug tracker first.
The latest SPICE code can be found in GIT at:
https://gitlab.freedesktop.org/spice/
Licensing
---------
SPICE is provided under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
Please see the COPYING file for the complete LGPLv2+ license
terms, or visit <http://www.gnu.org/licenses/>.
Experimental Features
---------------------
To enable multiple client connections, set:
SPICE_DEBUG_ALLOW_MC=1
-- End of readme