<div dir="ltr">Hi Daniel,<div><br></div><div>Thanks for doing this!</div><div><br></div><div>I share a lot of the same background - I've worked with autotools for many years, know them well and have also been hesitant to move away. I've recently ported a small personal project from autotools to meson and I found it very nice and easy to work with. It feels like a better fit for the kind of workflow that I'm used to with autotools than many of the other newer build systems out there.</div><div><br></div><div>In terms of speed, it's certainly nice that meson ends up using ninja, but the much faster configure step is what I'm excited about. Especially on a multicore system where the configure step runs single-threaded and bottlenecks the rest of the otherwise parallelizable build process. And the fact that meson is fast enough that there's no point in a separate autogen.sh step, make the overall system much simpler and faster.</div><div><br></div><div>Of course, one of the points of the generate step in autotools is that you ship the generated files with your tarballs and the end results only requires standard sh and make. I don't think meson has a similar feature, but I'd argue that today requiring python isn't going to limit you any more than requiring sh and make.</div><div><br></div><div>I think having both meson and autotools side by side for a bit would be a good way to start and I'd be in favor of moving to meson exclusively a few releases down the road.<br></div><div><br></div><div>Kristian</div><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 29, 2016 at 9:00 AM Daniel Stone <<a href="mailto:daniels@collabora.com">daniels@collabora.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br class="gmail_msg">
Whilst working on the atomic series, and the recent review spree, I<br class="gmail_msg">
started to really lose patience with how incredibly slow our build<br class="gmail_msg">
system is.<br class="gmail_msg">
<br class="gmail_msg">
This patchset provides a working port to Meson, a Python-based build<br class="gmail_msg">
system with a Ninja backend. Whilst autotools runs a combination of<br class="gmail_msg">
shell and Perl (aclocal/automake/autoconf) to generate the build files<br class="gmail_msg">
and Make and shell to run it, Meson runs its configuration step in<br class="gmail_msg">
Python, and outputs Ninja build files.<br class="gmail_msg">
<br class="gmail_msg">
(tl;dr: smaller platforms 3-6x quicker, bigger platforms 2-4x quicker)<br class="gmail_msg">
<br class="gmail_msg">
There are a few things which attracted me to Meson. It's really,<br class="gmail_msg">
mindblowingly, fast. There's no artificial split between configure and<br class="gmail_msg">
build stages (i.e. <a href="http://configure.ac" rel="noreferrer" class="gmail_msg" target="_blank">configure.ac</a> vs. Makefile.am). Its dependencies are<br class="gmail_msg">
quite lightweight. It has first-class support for pkg-config, and I've<br class="gmail_msg">
not had a problem with executables, shared libraries, modules, static<br class="gmail_msg">
helper libraries, binaries to install to libexec, tests[0], etc etc.<br class="gmail_msg">
<br class="gmail_msg">
I've been keeping an eye on it for a while as it matures; one of the<br class="gmail_msg">
things which interested me was seeing GStreamer and GNOME start to<br class="gmail_msg">
migrate some of their projects towards it. Not because they're<br class="gmail_msg">
incredible and we should blindly follow everything they do, but because<br class="gmail_msg">
they have a very similar set of build-system requirements to us, and<br class="gmail_msg">
they have also been very conservative in migrating away from autotools<br class="gmail_msg">
to date.<br class="gmail_msg">
<br class="gmail_msg">
I'm incredibly familiar with autotools, dating back to 2004 when I<br class="gmail_msg">
started experimenting with converting the X server to use it, which<br class="gmail_msg">
later grew into the xserver module we have today. As new build systems<br class="gmail_msg">
have come around, I've made a point of looking into them, and trying to<br class="gmail_msg">
use them.<br class="gmail_msg">
<br class="gmail_msg">
SCons and waf were immediately disqualified, because I think writing<br class="gmail_msg">
your entire build in actual Python is insane, and too large a barrier to<br class="gmail_msg">
entry. CMake is brutally slow[1], I find its interface very unintuitive,<br class="gmail_msg">
and cmake --help-full splits out a 37,399-line Markup file to stdout. GN<br class="gmail_msg">
(used for Chrome) is very nice, and I prefer its system of 'configs' to<br class="gmail_msg">
Meson's per-target flags, but isn't really portable. Most of the rest<br class="gmail_msg">
focus on languages we don't use, and/or bring massive dependencies.<br class="gmail_msg">
<br class="gmail_msg">
Meson's the first one I've found that strikes the right balance (not<br class="gmail_msg">
perfect, but within striking distance) of lightweight DSL vs. useful<br class="gmail_msg">
programming language. And, it's really incredibly fast. It has far<br class="gmail_msg">
better support for cross-compilation and sysroots than autotools can<br class="gmail_msg">
ever hope to have. And it's got quite a good upstream community behind<br class="gmail_msg">
it, and solid documentation.<br class="gmail_msg">
<br class="gmail_msg">
I've done a port for Meson, with the full range of options and<br class="gmail_msg">
configuration available in autotools today. Currently we're missing<br class="gmail_msg">
Doxygen support (because I haven't got around to it) in Wayland, plus I<br class="gmail_msg">
haven't been able to test the Weston RDP backend (because it doesn't<br class="gmail_msg">
build in Fedora 25) or the fbdev backend (because it's 2016), but they<br class="gmail_msg">
are there. There's also currently no support for 'auto' build options; I<br class="gmail_msg">
need to look into how best to do that. A couple of the tests in Weston<br class="gmail_msg">
are missing, and I think also PAM support for weston-launch.<br class="gmail_msg">
<br class="gmail_msg">
There are also some inefficiencies: currently, for some reason, Meson<br class="gmail_msg">
will run wayland-scanner once for every generated file _for every<br class="gmail_msg">
target_. So xdg-shell-unstable-v5-client-protocol.h, for example, gets<br class="gmail_msg">
built a bazillion times. Fixing that upstream would actually visibly cut<br class="gmail_msg">
the build times. We could also get a speed boost by moving away from<br class="gmail_msg">
config.h and using per-target build flags, to avoid unnecessary<br class="gmail_msg">
rebuilds: this doesn't work with autotools as it only rebuilds if<br class="gmail_msg">
dependent mtimes change, but Meson/Ninja hash the build flags and force<br class="gmail_msg">
a rebuild if those change. I'm going to be looking into that later.<br class="gmail_msg">
<br class="gmail_msg">
It's also smaller than our existing files: 374 lines for Meson versus<br class="gmail_msg">
481 lines for <a href="http://configure.ac/Makefile.am" rel="noreferrer" class="gmail_msg" target="_blank">configure.ac/Makefile.am</a> (excluding doc) in Wayland, and<br class="gmail_msg">
1602 lines for Meson versus 2373 lines for<br class="gmail_msg">
<a href="http://configure.ac/Makefile.am/weston-tests-env" rel="noreferrer" class="gmail_msg" target="_blank">configure.ac/Makefile.am/weston-tests-env</a> in Weston.<br class="gmail_msg">
<br class="gmail_msg">
This conversion requires Meson 0.36, which is available in Fedora 25 and<br class="gmail_msg">
Debian testing/stretch. It's not available in Ubuntu release versions or<br class="gmail_msg">
Debian stable/jessie; it can, however, be easily installed through pip<br class="gmail_msg">
on these systems.<br class="gmail_msg">
<br class="gmail_msg">
Thanks for this go to the very helpful people on Freenode #mesonbuild,<br class="gmail_msg">
as well as to the authors of the GStreamer Meson port, who stated that<br class="gmail_msg">
they did not assert copyrightability over their build files, allowing<br class="gmail_msg">
me to use some of those as inspiration for this port.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
Anyway, here are some benchmarks I've done on build times, across the<br class="gmail_msg">
full range of the computing-power spectrum:<br class="gmail_msg">
<br class="gmail_msg">
System 1 ('RPi2'): Raspberry Pi 2, 900MHz quad-core ARM Cortex-A7, 1GB<br class="gmail_msg">
RAM, storage on SD card, make -j8<br class="gmail_msg">
<br class="gmail_msg">
System 2 ('Rock2'): Radxa Rock2 Square, Rockchip RK3288 SOC, 1.6GHz<br class="gmail_msg">
quad-core ARM Cortex-A17, 2GB RAM, storage on eMMC, make -j8<br class="gmail_msg">
<br class="gmail_msg">
System 3 ('Laptop'): Dell XPS 13 9350, 2.5GHz dual-core Intel Skylake<br class="gmail_msg">
i7-6500U, 4MB cache, 16GB RAM, storage on NVME/PCI-E, make -j8<br class="gmail_msg">
<br class="gmail_msg">
System 4 ('Xeon'): HP Z840, 2.4GHz 14-core Intel Broadwell Xeon<br class="gmail_msg">
E5-2680v4, 35MB cache, 128GB RAM, storage on NVME/PCI-E, make -j18[2]<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
Wayland<br class="gmail_msg">
-------<br class="gmail_msg">
<br class="gmail_msg">
Documentation is disabled to give an apples-to-apples comparison; also<br class="gmail_msg">
Meson's default use of ccache is disabled for the same reason. 'make<br class="gmail_msg">
install' is split into a separate make invocation, because it fails in a<br class="gmail_msg">
dependency-relinking catastrophe otherwise.<br class="gmail_msg">
<br class="gmail_msg">
Note that the time involving test is mostly dominated by sanity-test,<br class="gmail_msg">
which takes around 5.7s (!). If you subtract that from the runtimes, the<br class="gmail_msg">
differentials for the faster machines becomes far more apparent.<br class="gmail_msg">
<br class="gmail_msg">
Test 1 ('full'): full configuration, build, test, and install<br class="gmail_msg">
  - time (../autogen.sh --prefix=/tmp/wayland-autotools --disable-documentation && make -j$JOBS check && make install)<br class="gmail_msg">
  - time (CC=gcc meson --prefix=/tmp/wayland-meson .. && ninja test install)<br class="gmail_msg">
<br class="gmail_msg">
Test 2 ('rebuild'): full rebuild and install<br class="gmail_msg">
  - touch ../src/wayland-util.h && time (make -j$JOBS && make check install)<br class="gmail_msg">
  - touch ../src/wayland-util.h && time (ninja test install)<br class="gmail_msg">
<br class="gmail_msg">
Test 3 ('check'): relink libweston and test<br class="gmail_msg">
  - touch ../src/wayland-server.c && time (make -j$JOBS check)<br class="gmail_msg">
  - touch ../src/wayland-server.c && time (ninja test)<br class="gmail_msg">
<br class="gmail_msg">
Test 4 ('install'): no changes, install<br class="gmail_msg">
  - time make install<br class="gmail_msg">
  - time ninja install<br class="gmail_msg">
<br class="gmail_msg">
         |             RPi2 |           Rock2 |          Laptop |           Xeon |<br class="gmail_msg">
---------+------------------+-----------------+-----------------+----------------+<br class="gmail_msg">
Full     | 353.34s / 65.78s | 96.80s / 25.30s | 27.78s / 11.24s | 22.71s / 7.19s |<br class="gmail_msg">
Rebuild  | 103.73s / 53.83s | 43.61s / 16.17s | 13.80s /  9.63s | 10.87s / 6.12s |<br class="gmail_msg">
Check    |  44.67s / 14.76s | 17.63s /  7.23s | 13.22s /  8.80s |  6.67s / 5.41s |<br class="gmail_msg">
Install  |   6.39s /  3.46s |  1.71s /  1.13s |  0.47s /  0.14s |  0.75s / 0.36s |<br class="gmail_msg">
---------+------------------+-----------------+-----------------+----------------+<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
Weston<br class="gmail_msg">
-------<br class="gmail_msg">
<br class="gmail_msg">
Documentation is disabled to give an apples-to-apples comparison; also<br class="gmail_msg">
Meson's default use of ccache is disabled for the same reason. 'make<br class="gmail_msg">
install' is split into a separate make invocation, because it fails in a<br class="gmail_msg">
dependency-relinking catastrophe otherwise. The RDP backend is disabled<br class="gmail_msg">
for both, so I can actually build it on Fedora.<br class="gmail_msg">
<br class="gmail_msg">
Test 1 ('full'): full configuration, build, test, and install<br class="gmail_msg">
  - time (../autogen.sh --prefix=/tmp/weston-autotools --disable-rdp-compositor --disable-devdocs --disable-setuid-install && make -j$JOBS check && make install)<br class="gmail_msg">
  - time (CC=gcc meson --prefix=/tmp/weston-meson -Dbackend_rdp=false .. && ninja test install)<br class="gmail_msg">
  + -Dclients_dmabuf_drm=false / --disable-simple-dmabuf-intel-client on the ARM systems<br class="gmail_msg">
<br class="gmail_msg">
Test 2 ('rebuild'): full rebuild and install<br class="gmail_msg">
  - touch ../libweston/compositor.h && time (make -j$JOBS && make check install)<br class="gmail_msg">
  - touch ../libweston/compositor.h && time (ninja test install)<br class="gmail_msg">
<br class="gmail_msg">
Test 3 ('check'): relink libweston and test<br class="gmail_msg">
  - touch ../libweston/timeline.c && time (make -j$JOBS check)<br class="gmail_msg">
  - touch ../libweston/timeline.c && time (ninja test)<br class="gmail_msg">
<br class="gmail_msg">
Test 4 ('install'): no changes, install<br class="gmail_msg">
  - time make install<br class="gmail_msg">
  - time ninja install<br class="gmail_msg">
<br class="gmail_msg">
         |              RPi2 |            Rock2 |          Laptop |           Xeon |<br class="gmail_msg">
---------+-------------------+------------------+-----------------+----------------+<br class="gmail_msg">
Full     | 685.80s / 163.20s | 188.55s / 34.55s | 53.96s / 12.47s | 25.78s / 6.26s |<br class="gmail_msg">
Rebuild  | 231.78s /  77.62s |  62.26s / 19.45s | 25.75s /  6.81s | 14.25s / 4.80s |<br class="gmail_msg">
Check    |  37.21s /  27.18s |  12.00s /  6.82s |  4.91s /  3.22s |  4.42s / 3.65s |<br class="gmail_msg">
Install  |  21.32s /   7.31s |   7.03s /  1.98s |  1.63s /  0.38s |  2.23s / 0.73s |<br class="gmail_msg">
---------+-------------------+------------------+-----------------+----------------+<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
Cheers,<br class="gmail_msg">
Daniel<br class="gmail_msg">
<br class="gmail_msg">
[0]: Support for skipping tests has still not quite yet landed, which is<br class="gmail_msg">
     a black mark indeed: <a href="https://github.com/mesonbuild/meson/pull/1110" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/mesonbuild/meson/pull/1110</a><br class="gmail_msg">
[1]: cf. <a href="https://lwn.net/Articles/706653/" rel="noreferrer" class="gmail_msg" target="_blank">https://lwn.net/Articles/706653/</a> and thread<br class="gmail_msg">
[2]: This would be -j28, but the build just fails at higher parallelism<br class="gmail_msg">
     levels. I don't know why.<br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
wayland-devel mailing list<br class="gmail_msg">
<a href="mailto:wayland-devel@lists.freedesktop.org" class="gmail_msg" target="_blank">wayland-devel@lists.freedesktop.org</a><br class="gmail_msg">
<a href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br class="gmail_msg">
</blockquote></div></div></div>