Commit Graph

5 Commits

Author SHA1 Message Date
Frediano Ziglio
2060672e81 Create common header for demarshallers declarations
Code generated for demarshallers define and declare some types and
functions.
However these types and functions are also declared separately in other
headers (currently spice-common/client_demarshallers.h and
spice/server/demarshallers.h) resulting in potential ABI mismatch if the
different declarations do not match.
Using a common header shared between generated code and code using
these functions prevent potentially multiple different declarations.

Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
2018-10-15 13:31:16 +01:00
Frediano Ziglio
7d16536672 proto: Remove support for SPICE version 1
SPICE version 2 was introduced more than 8 years ago.
RHEL 6 already removed support for version 1 in the server.

Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
2018-09-28 09:00:03 +01:00
Christophe Fergeau
b4e07c31cf build: Remove spice_common.h
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>
2018-07-06 06:46:15 +01:00
Christophe Fergeau
992ebac6b5 build: Remove bitops.h
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>
2018-06-05 14:10:22 +01:00
Eduardo Lima (Etrunko)
55070333f6 Add support for building with meson/ninja
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: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
2018-06-01 21:27:04 +01:00