Current bumped and age bumped for new intefaces only (no backward
incompatible changes).
New libtool version is 2.0.1, using --version-info instead of
--version-name. Doing the version change and --version-name to
--version-info change here to avoid changing the libtool version twice.
Added interfaces:
spice_server_set_name
spice_server_set_uuid
spice_server_set_listen_socket_fd
spice_server_is_server_mouse
New library name in linux:
libspice-server.so.1.1.0
Old:
libspice-server.so.1.0.2
Consolidate two separate chunks of library hunting that depend on the
same check.
Check if we're actually building the client before looking for
client only libraries.
Hide some of the final output if we're not building the client.
The client/common.h file defines __STDC_FORMAT_MACROS before
including inttypes.h so that the PRI* macros get defined in
C++. This is ignoring the possibility that other global
includes may have already pulled in inttypes.h
We need __STDC_FORMAT_MACROS to be defined before any header
files are included. Putting it in config.h satisfies this,
since config.h is always the first header
* m4/manywarnings.m4m, m4/warnings.m4: Import GNULIB warnings
modules
* m4/spice-compile-warnings.m4: Define SPICE_COMPILE_WARNINGS
* configure.ac: Replace compile warning check with a call to
SPICE_COMPILE_WARNINGS
* client/Makefile.am: Use WARN_CXXFLAGS instead of WARN_CFLAGS
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This patch will replace the common/ directory with the spice-common
project. It is for now a simple project subdirectory shared with
spice-gtk, but the goal is to make it a proper library later on.
With this change, the spice-server build is broken. The following
commits fix the build, and have been seperated to ease the review.
v2
- moves all the generated marshallers to spice-common library
- don't attempt to fix windows VS build, which should somehow be
splitted with spice-common (or built from tarball only to avoid
generation tools/libs deps)
v3
- uses libspice-common-client
- fix a mutex.h inclusion reported by Alon
This is supported by the GNU linker, but not the Solaris linker, which
is used as the default on that platform even when compiling with GCC.
Omit passing the option to the linker on platforms that do not support
it.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
As suggested by Alon, a simple automated test to try to find
regressions in Spice code.
To use this, compile Spice with --enable-automated-tests and
run test_display_streaming passing --automated-tests as parameter.
This matches what we do in client/Makefile.am to actually run the
python scripts, which is to use the python binary we find first,
preferring 'python2' over 'python'. This makes the compile work on odd
systems such as Arch Linux where the python binary is actually python3.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
RHEL-6 Bugzilla: 695323
cherry-picked from qspice commit
003667ac99beeec9b330a07bc3569c59a96d4588
which fixes RHEL-5 541566
with merge of the one line qspice fix to SPICE_REQUIRES:
9f3fe4755f11044a45c4b21148466a997fcbf735
spice: fixed reference to xinerama pkg config file
(Xinerama.pc=>xinerama.pc)
Author: Yonit Halperin <yhalperi@redhat.com>
Add a backtrace printing function copied from xserver os/backtrace.c
that uses gstack, and if that isn't found then glibc's backtrace.
Used in ASSERT, tested on F15.
Check both in configure.ac (after checking if we need to rebuild
the marshalling files) and in the python script using pyparsing
(for people modifying .proto files in tarballs)
Now that all source files include config.h, we can use AC_DEFINE
to enable/disable optional features (opengl, cegui). This is
cleaner than directly appending -Dxxx directives to the preprocessor
flags. This also guarantees that everything will be appropriately
rebuilt when using the same source tree to build first with opengl
support and then without (the config.h timestamp will change,
triggering a rebuild of the files including it)
spice Makefile.am setup is a bit confusing, with source file
names being listed several times in different Makefile.am
(generally, once in EXTRA_DIST and another time in another
Makefile.am in _SOURCES). The client binaries are built
by client/x11/Makefile.am, which means recursing into client,
then into x11 to finally build spicec. This Makefile.am is
also referencing files from common/ and client/, which is
a bit unusual with autotools.
This patch attempts to simplify the build process to get
something more usual from an autotools point of view.
The source from common/ are compiled into a libtool convenience
library, which the server and the client links against which avoids
referencing source files from common/ when building the server and
the client. The client is built in client/Makefile.am and directly
builds files from x11/ windows/ and gui/ if needed (without
recursing in these subdirectories).
This makes the build simpler to understand, and also makes it
possible to list source files once, which avoids potential
make distcheck breakage when adding new files.
There is a regression in this patch with respect to
sw_canvas/gl_canvas/gdi_canvas. They should be built with
different preprocessor #defines resulting in different behaviour
of the canvas for the client and the server. However, this is not
currently the case, both the client and the server will use the same
code for now (which probably means one of them is broken). This will
be fixed in a subsequent commit.
make distcheck passes, but compilation on windows using the
autotools build system hasn't been tested, which means it's likely
to be broken. It shouldn't be too hard ot fix it though, just let
me know of any issues with this.
configure.ac defines a SPICEC_STATIC_LINKAGE_BDYNAMIC variable
when --enable-static-linkage is not set, but it's never used.
SPICEC_STATIC_LINKAGE_BSTATIC is used in client/, but since we
are using libtool, it might be more appropriate to use
'make LDFLAGS="-all-static"' to achieve static link.
Most uses of AC_ARG_ENABLE were buggy:
- when passing --disable-xxx, configure.ac would behave as if it
was passed --enable-xxx
- passing --enable-xxx=foo would "leak" into the summary, ie the
summary (at the end of configure) would say "xxx: foo" instead
of "xxx: yes"
This patch fixes these 2 issues.
spice configure.ac has some code to detect if the compiler has
a special attribute to tag some functions so that they generate a
warning when their return value isn't checked. However, this test
is broken (the gcc attribute name is "warn_unused_result", not
"__warn_unused_result__" and WARN_UNUSED_RESULT is unused anyway
since spice-protocol provides SPICE_GNUC_WARN_UNUSED_RESULT. Thus
we can just drop that block of code from configure.ac
This patch make it easier to spot warnings in compilation. It should
work with older versions of automake that don't support silent rules.
If you want verbose build, make V=1.
Signed-off-by: Uri Lublin <uril@redhat.com>
https://bugs.freedesktop.org/show_bug.cgi?id=34795
Only the client needs this, and erronously using SPICE_REQUIRES
results in libcacard dep in spice-server.pc, which is then dragged
into qemu when linking, beeing used instead of the builtin libcacard.
