This flag disable some compiler feature which is used by some system header
potentially introducing some limitations.
Autotools won't add any flag to limit compiler features to C99, instead it
currently only add flags to support C99 when needed.
For instance some Posix limitations changes (like _POSIX_OPEN_MAX).
As compiler feature for instance _Static_assert is not used.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
We can follow the same practice as in headers and function checks above,
by using the dependency name itself to set the configuration data.
Also, if a combo is used, the first value is used as default if none is
specified. Thus, we can remove the default value for opus from
meson_options.txt.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
The only file preventing this flag was bitops.h which has been removed
since the following commit:
commit 992ebac6b5
Author: Christophe Fergeau <cfergeau@redhat.com>
Date: Tue Jun 5 11:27:01 2018 +0200
build: Remove bitops.h
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Nothing in spice-common calls vfork. The autotools-based build can
fallback to vfork if fork is not available/working through the
AC_FUNC_FORK macro, but the meson build is not implementing this magic.
However, fork() is only called once in backtrace.h, and this part of the
code is optional (it's not compiled in on Windows for example), and
anyway, I doubt anyone is going to try to compile SPICE code on a
platform without fork, so we can remove this check, it's always possible
to readd it when we have a clear bug report about what is
missing/needed.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
At the moment, missing optional dependencies will be silently ignored
when the corresponding configuration flag is 'true', and won't be tested
for when the flag is 'false'.
In the autotools build, this corresponds respectively to
--enable-foo=auto and --disable-foo.
Having a way to get an error when the package is enabled but missing is
quite desirable. f52247384 has some half-baked attempt at that, but this
was supposed to be removed from the series. This causes errors when
processing meson.build, breaking the meson build.
This commit adds 'true'/'false'/'auto' in a proper way.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Grepping for 'pow', 'sqrt' or 'inet_ntoa' returns no results in
spice-common code base.
inet_ntoa use was removed in 9749e7e 'ssl-verify: Changed IPv4 hostname
to IPv6' and pow/sqrt use in 384698a 'Remove GL support'
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Following the commit disabling celt by default, it's quite easy to have
a build without both celt and opus. After this commit, Opus will have to
be installed for a successful build unless one passes --disable-opus.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
lines.c uses hypot(), which is found in libm on some systems. This means
we are currently relying on getting -lm indirectly through some other
means, as otherwise linking any binary with spice-common would fail.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@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: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
