In configure.ac the micro version is incremented if there is a
forth component in the version.
In Meson this was wrongly translated to "if contains git".
This fixes Gitlab issue #46.
Signed-off-by: Frediano Ziglio <freddy77@gmail.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
When `build-aux/git-version-gen` is not able to find the project
version (no git tags and no `.tarball-version`), it returns 'UNKNOWN'
(instead of the project version like `0.14.3.185-15b1`).
This `UNKNOWN` value fails `meson build` command:
server/meson.build:8:0: ERROR: Index 1 out of bounds of array of size 1.
With this patch, we set a default major/minor/micro value when the
actual version is unknown. This is the same as the `autoconf`
historical behavior.
Fixes#41.
Signed-off-by: Kevin Pouget <kpouget@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
We don't use anymore GObject parameters so avoid having to
register enum values to GType system to use them.
We just need to get the nick value of the enum values for
debug purposes.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Instead of including spice.h directly include an header that wraps
it. This allows to remove the SPICE_SERVER_INTERNAL define.
Currently is used to rename SpiceCharDeviceInstance to RedCharDevice
and reduce its visibility to hidden. This remove some warnings
and some weird code in the source.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
The reason to not using STL is that our code from how was designed requires
the iterator to be safe to the delete of the element pointed by the iterator.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
The existing .pc file had the wrong dependencies for Windows and was
missing the optional private dependencies for static linking.
Signed-off-by: James Le Cuirot <chewi@gentoo.org>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Distributions like to be in control of this.
From a patch from James Le Cuirot.
Instead of always build both shared and static libraries for
SPICE server (static is used for the tests) compile library
as user requested. In case we need the static library for tests
(which now can be disabled) create a static library extracting
objects from shared library.
This also fixes the problem that Meson installed the static
library even if not requested and just used for tests.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Not used since 03d46e9e "build-sys: Raise glib requirement to 2.38" in
2019-02-05
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
We do this by auto detecting the inbound http(s) 'GET' and probing
for a well formulated WebSocket binary connection, such as used
by the spice-html5 client. If detected, we implement a set of
cover functions that abstract the read/write/writev functions,
in a fashion similar to the SASL implementation.
This includes a limited implementation of the WebSocket protocol,
sufficient for our purposes.
Signed-off-by: Jeremy White <jwhite@codeweavers.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This header was removed in 2014 (3c6b4e415) as deprecated and added again
in 2015 (2e88eb705) as causing some issue with former Qemu versions.
After 4 years remove again, now there should not be any usage of it.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Snir Sheriber <ssheribe@redhat.com>
Between Unix and Windows socket are quite different:
- on Windows sockets have a different namespace from C file
descriptors so you can't use read/write/close or similar functions;
- errors are not stored in errno but you must be read/write the
errors with specific function;
- sometimes sockets are put in non-blocking mode automatically
calling some functions;
- SOCKET type is 64 bit on Windows 64 which does not fit technically
in an int. Is however safe to assume them to fit in an int.
So encapsulate the socket APIs in some definition to make easier
and more safe to deal with them.
Where the portability to Windows would make to code more offuscated a Unix
style was preferred. For instance if errors are detected errno is set from
Windows socket error instead of changing all code handling.
Fortunately on Windows Qemu core interface accepts socket (but not
other types like C file descriptors!).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Reviewed-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>
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>
