In case version script support is not available we can still
able to filter symbols exported.
This for instance will work with linkers not supporting
--version-script (like system MacOS one).
Use new version macros similar to Glib to detect also
deprecated function.
Tested that exported symbols remains the same from both Linux
and Windows shared libraries.
Signed-off-by: Frediano Ziglio <freddy77@gmail.com>
Remove a race condition testing code with no libusb enabled.
Setting libusb_context field while the libusb event thread was using
causes a potential deadlock in the test.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
This fixes building spice-gtk on Debian 10.
See https://github.com/mesonbuild/meson/issues/4720.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Uri Lublin <uril@redhat.com>
Although currently not supported by the code (libusb_context in
SpiceUsbBackend is never NULL), try to support it in order to be able to
have only emulated devices if the libusb layer is failing.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Currently we call this function when the SPICE channel is up
however this function should continue to work as in theory
the channel could avoid to handle the message and stop the flow
(for instance to implement some kind of flow limitation)
and so will need to call this function again.
This was failing in the first USB emulation implementation
causing a crash.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Mock some usb-backend functions to be able to simulate device
attachment and detachment.
Create session and channel to pass some valid pointer anyway.
Emulate channel state correctly.
Make sure HELLO packets are sent correctly at the beginning and
no more afterwards.
Test auto-connect enabled or disabled.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Instead of linking all object inside spice-client-glib build a library
from these object and link to each test.
This will allow to override some object file for mocking purposes.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Just allocate and free to test for base leaks and reference
counting.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Maintaining 1 build system is hard. Maintaining 2 is even harder.
It seems the meson build system is now in good shape to replace
autotools. Like many desktop projects, let's move entirely to meson
and drop autotools support.
Known changes:
- generating changelog files in the dist tarball. This is not strictly
required, and can be added back later.
- generated files are not included in the dist tarball. In some ways,
this can be considered a good thing.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Currently, spice-gtk tests are disabled if build of static libraries is
disabled. This commit introduces an intermediate
spice-client-glib-impl.la convenience library which will be used both
for generating the spice-client-glib-2.0 shared library (after applying
the version script), and to link the tests with.
This is better than using --enable-static as we don't need to rebuild
each object twice (static and shared).
This was inspired by similar work Fabiano Fidencio did in libosinfo:
https://www.redhat.com/archives/libosinfo/2018-November/msg00231.html
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Meson waits for pipes (stdout and stderr) to be not readable but
our mocking helper does not close these handles causing Meson
to exit with a stack trace.
Note that the fact that the helper is not closing the handles
is a wanted behaviour.
Already reported at https://github.com/mesonbuild/meson/issues/3967.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@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: Victor Toso <victortoso@redhat.com>
Build complains about lots of unitialized fields in TestCase definition,
for instance:
../tests/session.c:276:11: warning: missing initializer for field ‘message’ of ‘TestCase {aka const struct <anonymous>}’ [-Wmissing-field-initializers]
"spice://[::192.9.5.5]:5910" },
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../tests/session.c:11:18: note: ‘message’ declared here
const gchar *message;
^~~~~~~
../tests/session.c:282:11: warning: missing initializer for field ‘unix_path’ of ‘TestCase {aka const struct <anonymous>}’ [-Wmissing-field-initializers]
"password may be visible in process listings"},
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
They couldn't not be introduced before, because the test needs both
parsing and generation.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
For some reason, the URIs test didn't include spice+unix:// checks,
probably because they came about the same time.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
The peer stream may be closed, but may have failed to close self,
because it has pending operations. In this case indicate EOS on read
rather than returning an error. self will be close eventually on
dispose.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
At the moment:
- Fedora 26 has 2.52
- Fedora 25 has 2.50
- Fedora 24 has 2.48
- CentOS 7 has 2.46
- Debian 9 has 2.50
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
With -Wall a few -Wunused-variable and -Wunused-but-set-variable;
With -Wextra lots of -Wunused-parameter and a few -Wsign-compare.
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
The parameter is removed from functions:
get_line
spice_convert_newlines
spice_unix2dos
spice_dos2unix
It was introduced in 75f1ea3ee9
but never used
Acked-by: Marc-André Lureau <mlureau@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
The GFileInfo returned by spice_file_transfer_task_init_task_finish()
must be unref'ed when no longer needed.
Acked-by: Victor Toso <victortoso@redhat.com>
Agent only can only send error or cancel from a transfer operation
after it was initialized. From SpiceFileTransferTask point of view,
error and cancellation is an GError with different code so testing
only cancel seems enough.
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This only includes a simple test for file-transfer with a small
summary of the possible situations of the test.
As the test is specifically for SpiceFileTransferTask, we don't create
a SpiceMainChannel.
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
In file included from
../spice-common/common/client_marshallers.h:29:0,
from ../src/spice-channel-priv.h:35,
from ../src/spice-file-transfer-task-priv.h:28,
from file-transfer.c:3:
../spice-common/common/messages.h:45:23: fatal error: libcacard.h: No such file or directory
compilation terminated.
Acked-by: Pavel Grunt <pgrunt@redhat.com>
