[RFC PATCH 0/8] Meson build system

Wed Nov 30 01:02:13 UTC 2016

On 29 November 2016 at 20:50, Daniel Stone <daniel at fooishbar.org> wrote:
> Hey Emil,
>
> On 29 November 2016 at 20:41, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> My voice doesn't carry much weight on wayland-devel still I think it
>> will bring some nice food for thought.
>>
>> As you know better than me the actual speed increase isn't in using
>> Meson, it's due to ninja.
>>
>> If one is to use (write?) make backend for Meson the results wouldn't
>> be that different.
>
> I disagree. Using Ninja is nice, and a huge win, but there is already
> a massive, massive, massive, win before you invoke either Make or
> Ninja; just generating the configuration (autoreconf + ./configure vs.
> meson) is 16.75 seconds on my laptop (again, current-generation Intel
> with 16GB of RAM) for autotools, vs. 1.24 seconds for Meson. If
> they're equal, we'd have 53.96s vs. 28.0sec for the total build,
> rather than 53.96 vs. 12.47.
>
Thanks for the reminder how much configure sucks and how much faster
non-recursive makefiles are.
Numbers seems far better over here...

$ git clean -fXd -- .. && rm -rf * && time (../autogen.sh
--prefix=/tmp/wayland-autotools --disable-documentation)
~10 real

The rest of the number also seems to vary noticeably, despite having a
lower spec machine.
Using stock Arch here, should distro of choice matter that much ?

System 3 ('Laptop'): Dell XPS 13 9350, 2.5GHz dual-core Intel Skylake
i7-6500U, 4MB cache, 16GB RAM, storage on NVME/PCI-E, make -j8

System X ('Laptop 2'): Lenovo X1C3, 245GHz dual-core Intel Broadwell
i7-5500U, 4MB cache, 8GB RAM, storage on NVME/PCI-E, make -j8

NB: Everything but the Install test, varies ±0.2s across 3 consecutive
runs, thus it's been rounded to the closest 0.5s on average.

         |          Laptop |       Laptop 2 |
---------+-----------------+----------------+
Full     | 27.78s / 11.24s |   ~21s /  ~10s |
Rebuild  | 13.80s /  9.63s | ~12.5s / ~8.5s |
Check    | 13.22s /  8.80s |  ~7.5s / ~5.5s |
Install  |  0.47s /  0.14s |  0.47s / 0.14s |
---------+-----------------+----------------+

Having a close look at the functional discrepancies:
 - meson/ninja does not create static libraries, like autotools
Haven't tried unifying/checking.
 - meson checks for build_docs programs (toggle build_docs to false in
meson_options.txt)
Changing it makes no noticeable difference.
 - autotools builds fixed-benchmark
Removing it makes no noticeable difference.

So if we are to ignore configure time, numbers are comparable.
And yes, that's a very big if to ask for.

>> Writing an ninja backend for autotools on the other hand might be a
>> little bit harder.
>
> 'A little bit'.
>
Precisely. Thanks!

>> Last time I've looked neither make nor ninja scaled if JOB > actual
>> cores. Thus pushing -j8 on a RPi2 might be an overkill ;-)
>
> Ninja works on cores*2 by default AIUI, to match either the number of
> threads (relevant for my Intel machines). Even in the RPi case where
> it's not matching threads, it at least allows you to hide I/O latency
> a little bit, which is huge on an SD card ...
>
>> At the same time, -jJOBS seems to be missing in some of the make
>> invocations. Is that just in the summary here in the actual test runs
>> as well ?
>
> It's missing in make install, because parallelising
>
$ make -j100 check && make -j100 install
... works like a charm.

I've never tried doing both check and install targets at the same time
and I'm not sure if its legal.

>> As you know separate make and make install/check stages does force the
>> costly relink. slibtool [libtool rewrite in C] does not do that
>> although it does seem a bit slower in some of my testing. I'll need to
>> check with the author about addressing that.
>
> Slower again? How?!
>
Not sure what you mean here.

As we build (simple `make') binaries are linked against the in-tree
DSO(s). Upon `make install' autotools/libtool relinks each binary. The
latter of which can be quite costly.
One way around it is to hack into libtool with another to use a
project called slibtool (I've mentioned it a while back). The latter
links only once, thus in theory (at least) the whole thing could be
noticeably faster. For some reason normal linking with slibtool can be
a bit slow :-(

>> Last but not least:
>> Any ideas (did you see any threads) why so many people go and create
>> their own build system/tools rather than "beating some sense" into the
>> existing ones ? I'm yet to look into either ones of the autotools
>> components, having only a cutesy skim through libtool.
>
> Having worked with autotools quite a lot for the last 12 years, I
> can't say I was ever tempted to send a patch for it. Even just working
> around some of its more esoteric quirks and deficiencies (cf. magic
> relinking rules which kill parallelism) makes me lose the will to
> live. On the other hand, I found Meson very easy and accessible to
> work with, and had the pull request for skipping tests accepted today.
> I just can't ever imagine bringing myself to work on the beast which
> is autotools.
>
> Plus, what are you realistically going to do with it which would
> result in a 2-6x speed increase? It's used so widely that I cannot for
> the life of me imagine that it's only because of no-one working on it
> that it's this slow. I'm going to ascribe it more to being enormous
> piles of shell and Perl, compatible all the way back to some ancient
> AIX sh variant. Might be wrong, but ...
>
> Point is, autotools has literal decades to be this fast, and still
> isn't. To me, that points to deeper issues.
>
Was hoping that you've seen some threads and/or have some experience to share.

At the same time I your statement [above] states what I've find most
of the time.
People being unhappy with autotools, yet lacking the time/interest to
improve it :'-(

Please don't get me wrong, autohell^Wautotools is pretty annoying/etc
at times. Yet again I'm more of a person who would aim to improve
things before going to plan B.

Since wayland/weston uses non-recursive makefiles it's a matter of a)
removing the relinking and b) beating some sense into configure
(hiding most of the legacy tests?).
I'm afraid there's no 2-6x speed difference here and with the above
one could easily match (even surpass?) meson/ninja in some/most tests.

As a closing though: I wonder if I would be so nice and calm as you,
if I had used it for ~12 years.
I'm pretty sure things weren't as easy, in the yearly days, as they are today.

Thanks
Emil
P.S. Everyone the wayland series is here [1], use rev 1.
[1] https://patchwork.freedesktop.org/series/16113/