Skip to content
  1. Oct 01, 2018
  3. Sep 29, 2018
  5. Sep 28, 2018
  7. Sep 27, 2018
  9. Sep 26, 2018
  11. Sep 25, 2018
  13. Sep 24, 2018
  15. Sep 18, 2018
  17. Sep 05, 2018
  19. Sep 04, 2018
  21. Sep 03, 2018
  23. Aug 30, 2018
    • Eduardo Lima (Etrunko)'s avatar
      Update gitlab-ci to use meson · b08171cd
      Eduardo Lima (Etrunko) authored 
      

Signed-off-by: default avatarEduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: default avatarVictor Toso <victortoso@redhat.com>
      b08171cd
    • Eduardo Lima (Etrunko)'s avatar
      Add support for building with meson/ninja · 7a87356b
      Eduardo Lima (Etrunko) authored 
      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.html
    http://mesonbuild.com/Syntax.html
    http://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: default avatarEduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: default avatarVictor Toso <victortoso@redhat.com>
      7a87356b
  25. Aug 28, 2018
  27. Aug 27, 2018
  29. Aug 22, 2018
    • Jorge Olmos's avatar
      Avoid passing libusb functions as callbacks · 558c967e
      Jorge Olmos authored 
      When building spice-gtk for windows:
- libusb uses __stdcall calling convention when compiled for win32. It does
not include an option to be compiled with __cdecl calling convention.
Directly calling libusb functions works fine. But it is a problem when its
functions are passed as callbacks to a function that expects other calling
convention.
- glib uses __cdecl calling convention and expects the functions it
receives as parameters to follow __cdecl convention.

So the lines included in spice-gtk like:
     g_clear_pointer(&priv->device, libusb_unref_device);
cause libusb_unref_device (compiled with _stdcall convention) to be called
with __cdecl convention. This causes stack corruption, and hence crashes.

Related: https://gitlab.gnome.org/GNOME/glib/issues/1494


Acked-by: default avatarVictor Toso <victortoso@redhat.com>
      558c967e
  31. Aug 16, 2018
    • Frediano Ziglio's avatar
      Update spice-common submodule · 44f84a7f
      Frediano Ziglio authored 
      

This brings in the following changes:

Eduardo Lima (Etrunko) (5):
      ci: Fix typo: celt501 -> celt051
      meson: Make options accessible through parent project
      meson: Fix checking for python
      Meson: Make use of dictionary type introduced in version 0.47
      Meson: Make use of 'feature' option type introduced in version 0.47

Frediano Ziglio (2):
      ci: Fix Meson feature option
      Fix flexible array buffer overflow

Lukáš Hrázký (1):
      spice*.proto: Replace tabs with the appropriate number of spaces

Acked-by: default avatarEduardo Lima (Etrunko) <etrunko@redhat.com>
      44f84a7f
  33. Aug 14, 2018
  35. Aug 09, 2018