[RFC PATCH 0/8] Meson build system

[Daniel Stone]

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.

> Writing an ninja backend for autotools on the other hand might be a
> little bit harder.

'A little bit'.

> 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

> 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?!

> 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.

Cheers,
Daniel