Most users of spice_common.h don't need it, or only need log.h. It only
has a few users outside of spice-common. It's not very well defined
which headers it should contain. This commit removes spice_common.h in
favour of direct inclusion of the needed headers.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
These sources are only used by the client, so they do not belong in
libspice_common_la_SOURCES.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Nothing uses it since the GL backend was removed in 384698a
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>
This hack is now made obsolete by the previous commit. We can safely
remove those defines and the code now builds fine for both spice server
and spice-gtk.
commit df4ec5c318
Author: Frediano Ziglio <fziglio@redhat.com>
Date: Fri May 11 16:59:46 2018 +0100
Fix generation of Smartcard channel
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
As client_marshallers.h is included outisde of spice-common, we need to
specify the path for generated_marsharllers.h so that builds out of the
tree don't fail.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
This commit adds autogeneration of a generated_client_marshallers.h
header, which is then included in client_marshallers.h
This allows to remove the SpiceMessageMarshallers struct from this file,
which has to match what the generated code expects.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This reverts commit 7665dcf1bb.
Also revert the related build-sys changes to fix the build.
codegen generated code depends on spice-common code (marshaller,
messages etc), it makes more sense to keep the generator along
this. Otherwise a newer protocol release will fail to build older
projects.
*.proto files are required as well, since it generates code that parent
modules depend on unconditionnaly.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Now that spice-protocol ships the needed .proto files as well as the
corresponding python scripts, spice-common can use these in order to
generate the C code for the SPICE (de)marshallers.
Commit 4fafa210 added WARN_CFLAGS, VISIBILITY_HIDDEN_CFLAGS and
-std=gnu99 to AM_CFLAGS in common/Makefile.am, but these are not
needed. WARN_CFLAGS and VISIBILITY_HIDDEN_CFLAGS are not defined
anywhere in spice-common, and spice-common compiles fine without
-std=gnu99 on my f21 box.
These 2 files are not build as part of spice-common
build system, but modules using spice-common will build
them with the appropriate options. We need to let automake
know that these are source files so that it can properly
track these files dependencies.
Without this change, when eg spice-gtk switches to use 'subdir-objects'
to build sw_canvas.c as recommended by automake 1.14, the build
will fail because $(top_srcdir)/spice-common/common/.deps/sw_canvas.Plo
will not have been generated.
Now that they are created in $builddir, their includes will need to refer
to files in $srcdir, which can be different. It's cleaner to add
-I $(top_srcdir)/spice-common/ to modules using spice-common rather than
having -I $(top_srcdir)/spice-common/common which would could create header
collisions.
The rules to generate the .c/.h (de)marshalling files have targets based in
$builddir, but the CLIENT_MARSHALLERS/SERVER_MARSHALLERS list refer to
files in $srcdir.
When using a $srcdir != $builddir, these $srcdir files will not exist, and
it will not be possible to generate them, which causes the build to fail.
When using $srcdir == $builddir from git or from tarballs, this will not
make a difference. When building from git, if $srcdir and $builddir are the
same, then the files will be found regardless of if we look for them in
$srcdir or $builddir as they are the same.
In tarballs, the files will be shipped with the tarball and thus available
in $srcdir. As $builddir is the same as $srcdir, the files will already
exist and not be regenerated.
The only change of behaviour will be when using a tarball and doing a
$srcdir != $builddir build. In this case, the files will need to be
regenerated, so the tools needed for that must be installed on the
machine doing the build.
In addition to Laszlo's commit fixing rhbz#928973, we can add
some compile-time assertion to lz_common.h to help catch similar
bugs in the future.
This uses gnulib's verify.h to make sure at compile-time that
the various constant arrays used in lz_common.h are of the expected
size.
I've checked that before Laszlo's patch, the assert triggers, and
that it's gone after it.
The release tarballs ship with the generated files to avoid extra
build work and dependency. However, build was still tiggering a
regenration, because of Makefile change.
Avoid required rebuild when running ./configure (generating Makefile),
there is no variable that could be tweaked, afaict.
This file was hand generated until now, resulting in the wierd situation where
it is different for spice-gtk and spice-server even though they both use the
same spice-common and spice-protocol (or at least close) versions.
This patch generates the enums.h files from spice-common. While that file is
actually in the spice-protocol submodule, it cannot be generated from
spice-protocol since it lacks access to spice.proto and spice_codegen.py. So in
affect whenvever it will differ the spice-protocol module will become dirty and
hence hopefully commited with the new enums.h.
enums.h is generated from spice.proto is a superset of that generated from spice1.proto.
To allow the compile to detect incorrect printf formats, any
var-args function should have a format annotation
* common/macros.h: Helper to define ATTR_PRINTF for code
which can't depend on glib
* common/canvas_base.c, common/lz.h, common/macros.h: Annotate
some var-args methods
Be more library friendly, by not aborting in library errors.
spice_common now includes a proper log handler that will abort by
default when reaching a warning.
SPICE_ABORT_LEVEL can be changed to modify run-time abort level.
SPICE_DEBUG_LEVEL can be changed to be more verbose. By default, only
log level more importants than WARNING.
Only memory-related functions are allowed to abort(), since they are
not recoverable errors in the library.
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.
Code adapter from RedPeer::ssl_verify_callback() and used by
spice-gtk.
Since v1:
- fixed Makefile.am
- added config.h include
- autoconf alloca added in patch series
- moved int escape inside for loop
- added a failed case when missing assignment
- replaced strlen () by -1
- skip spaces after comma
- c++ guards
I didn't use bool, because openSSL uses int, and it is more future
proof for error reporting.
spice client and spice server shares code from
common/{gdi,gl,sw}_canvas.[ch]. However, while most of the code is
shared, the server code wants a canvas compiled with
SW_CANVAS_IMAGE_CACHE defined while the client code wants a canvas
compiled with SW_CANVAS_CACHE.
The initial autotools refactoring didn't take that into account,
this is now fixed by this commit. After this commit, the canvas
files from common/ are no longer compiled as part of the
libspice-common.la convenience library. Instead, there are "proxy"
canvas source files in client/ and server/ which #include the
appropriate C files after defining the relevant #define for the
binary that is being built.
To prevent misuse of the canvas c files and headers in common/,
SPICE_CANVAS_INTERNAL must be set when including the canvas headers
from common/ or when building the c files from common/ otherwise
the build will error out.
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.
This includes:
* pixman region from SpiceRects
* rop2 enum
* solid fill
* solid fill with rop
* tiled fill
* tiled fill with rop
* blit
* blit with rop
* copy rect
