[Spice-devel] [PATCH spice-gtk] Add support for building with meson/ninja

Eduardo Lima (Etrunko) etrunko at redhat.com
Mon Aug 6 13:42:22 UTC 2018


On 06/08/18 10:11, Victor Toso wrote:
> Hi,
> 
> On Wed, Aug 01, 2018 at 07:01:42PM -0300, Eduardo Lima (Etrunko) wrote:
>> 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 at redhat.com>
> 
> Great intro. So far, it looks good to me and I'd love to have
> this sooner than later so we can improve it quickly by using it
> during this release timeline.
> 
> I bumped glib and gtk and removed cast-function-type warning, all
> that is recent in git master.
> 
> diff --git a/meson.build b/meson.build
> index bed74f2..72518fc 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -44,7 +44,9 @@ compiler = meson.get_compiler('c')
>  spice_gtk_config_data = configuration_data()
>  spice_protocol_min_version='0.12.13'
>  spice_gtk_include = [include_directories('.')]
> -spice_gtk_c_args = []
> +spice_gtk_c_args = [
> +    '-Wno-cast-function-type',
> +]
>  spice_gtk_libs = []
>  spice_gtk_deps = []
>  spice_gtk_link_args = []
> @@ -89,7 +91,7 @@ endforeach
>  #
>  spice_protocol_version='0.12.15'
> 
> -glib_version = '2.38'
> +glib_version = '2.46'
>  glib_version_info = '>= @0@'.format(glib_version)
>  pixman_version = '>= 0.17.7'
> 
> @@ -140,7 +142,7 @@ endforeach
> 
>  # gtk
>  spice_gtk_has_gtk = false
> -spice_gtk_gtk_version_required = '>= 3.12'
> +spice_gtk_gtk_version_required = '>= 3.22'
>  if get_option('gtk')
>    gtk_dep = dependency('gtk+-3.0', version : spice_gtk_gtk_version_required)
>    gtk_encoded_version='GDK_VERSION_3_12'
> 
> I'll be playing around with it this week but this is already
> quite a big change that seems to be working well enough so I'd
> suggest to consider merging it by the end of the week if no one
> has major complains against it.
> 


Thanks for the comments, I will send another version with those changes
soon.

-- 
Eduardo de Barros Lima (Etrunko)
Software Engineer - RedHat
etrunko at redhat.com


More information about the Spice-devel mailing list