[Spice-devel] Build systems comparison

Mon Apr 2 12:22:39 UTC 2018

On 28/03/18 04:52, Christophe de Dinechin wrote:
> Following Eduardo’s sharing of his branch using Meson to build SPICE (https://gitlab.com/etrunko/spice/tree/meson), I ran some comparisons with the make-only build system I proposed late last year (https://github.com/c3d/spice/tree/c3d-build).
> 
> First, in case you want to reproduce, a bit of warning. Eduardo used some features that require a very recent Meson, more recent than what dnf gets me on a Fedora 27. So the best is to install Meson from git.

As teuf mentioned, the required version of meson is already in
updates-testing repository, so there is no more need to install from pip
or git either.

> 
> 
> I built the server with the three build systems, and the numbers you see are the best out of 5 runs (variations are small).
> 
> CLEAN BUILD TIME:
> 
> Build time after a git clean -dfx in ‘server’ and ‘spice-common’:
> 
> Autoconf: 56s
> Meson: 7.65s
> Make: 4.29s (debug), 19.21 (opt)
> 
> 
> INCREMENTAL BUILD TIME (SOURCE FILE):
> 
> Time after touching “server/reds.c”, which causes an incremental rebuild and linking.
> 
> Autoconf: 2.98s
> Meson: 2.98s
> Make: 0.62s (debug), 1.19s (opt)
> 
> Note that a difference here is that for the make case, the tests are not relinked until you run the test target.
> 
> 
> INCREMENTAL BUILD TIME (HEADER):
> 
> Time after touching “common/log.h”, which causes multiple rebuilds of dependencies
> 
> Autoconf: 22.6s
> Meson: 5.51s
> Make: 1.48s (debug), 2.96s (opt)
> 
> 
> PROJECT DESCRIPTION:
> 
> Autotools: 13 files, 1149 lines, 31.7K, using a combination of m4 + shell + make-like languages.
> Meson: 8 files, 553 lines, 16.4K, using a custom Python-like syntax
> Make: 7 files, 372 lines, 10.0K, using basic GNU make syntax
> 
> 
> BUILD COMMANDS (INITIAL BUILD):
> 
> Autoconf: autoreconf -vfi && ./configure && make
> Meson: meson build && ninja -C build
> Make: make
> 
> 
> BUILD COMMANDS (FOLLOW-UP BUILD):
> 
> Autoconf: make
> Meson: ninja -C build
> Make: make
> 
> 
> OTHER REMARKS:
> 
> At this point, Eduardo was more thorough than I was in reproducing the existing build faithfully. My own build, for example, only remakes the tests when the “make test” or “make check” option is called. This explains the difference in incremental build times (meson and autotools re-link all the server tests).

There was an issue with my build rules which added overhead to each
library/executable where the generated files from spice common were
built every time. It has been fixed now and the number steps went down
from 200+ to ~150, so there should be a noticeable improvement in build
times.

> 
> The Meson and make-only build systems offers a number of useful features, such as automatic logging.
> 
> There are presently some missing features in the make-based build system, notably generation of the package files and versioning (e.g. make dist, etc). This does not seem very hard to add.
> 
> The make-based build system also makes it possible to easily switch between “debug”, “opt" and “release” builds, and offers targets for example to reformat files, etc. I’ve not investigated to check if Meson offers something similar.

As I explained in the cover mail, the idea is to have different build
directories with different configurations, but I need to check if there
is automatic options for debug/release/optimized builds in meson or if
it is something we must do by ourselves.

> 
> The Meson build system apparently “takes over” submodules. The make-based build system uses the existing modules infrastructure.
> 

There is a workaround, to move the git submodule under 'submodules'
directory which can be used during the transition period. Thanks teuf again:

https://paste.fedoraproject.org/paste/byAmNhojehiq0rNDpolE9w

> The make branch I shared above also proposes a global layout for directories where “common” and “protocol” are built on the side, and not as part of “server” or “client”. A result of this is that if you change something in common, dependencies are rebuilt both in server and client, before you even commit. This helps verify that a ‘common’ change works both on the server and client without having to commit it and check it out in the two projects. This was useful for example during recorder development, where many changes were in “common”. As I understand it, the current Meson layout does not offer that property.
> 

I plan to do something similar, to prove that a single source tree would
be a huge improvement for us. It would require a top-level tree with the
meson.build file referring to protocol/common/server/gtk all as
submodules. That will require some changes to the current structure,
because it is not possible to have nested subprojects with Meson.

My idea at first was to have an unified repository, without projects
being independent from each other, but it seems that people were
reluctant about that idea. I still think it is a huge improvement in
development, and hopefully people maybe convinced about this when this
single build repository is up.

> I’ve extensively tested that the make-based approach can coexist with the autotools files. You can switch back and forth between the two build models. This may also be possible with Meson, but I have to understand how the meson subproject management can interfere with submodule layout.
> 
> I’ve tested the make-based files on macOS and Linux (and, for other projects, on Windows both with MinGW and Visual Studio). I only tested Meson only on Linux at this point. Meson itself is portable, I don’t know about the project descriptions.
> 

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