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. 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). 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. The Meson build system apparently “takes over” submodules. The make-based build system uses the existing modules infrastructure. 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’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. _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel