[Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Eric Anholt]

Alex Deucher <alexdeucher at gmail.com> writes:

> On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker <dylan at pnwbakers.com> wrote:
>> Why bother, and why would we want this?                                                              │~
>>
>> First it's written in python, which means the potential developer base
>> is massive. And it provides a recursive view for humans, but a
>> non-recursive view for the system. This is the best of both worlds,
>> humans can organize the build system in a way that makes sense, and the
>> machine gets a non-recursive build system. It also uses ninja rather
>> than make, and ninja is faster than make inherently. Meson is also a
>> simpler syntax than autotools or cmake it's not Turing Complete by
>> design nor does it expose python, again, by design. This allows meson
>> itself to be reimplemented in a another language if python becomes a
>> dead-end or a bottle-neck. It also makes it much easier to understand
>> what the build system is doing.
>>
>> What's different about using meson?
>>
>> Well, apart from a faster builds and less magic in the build system? The
>> configure flags are different, it uses -D<opt>=<value> more like cmake
>> than the --enable or --with flags of autotools, although oddly it uses
>> --prefix and friends when calling meson, but not with mesonconf, there's
>> a bug opened on this. Meson also doesn't support in-tree builds at all;
>> all builds are done out of tree. It also doesn't provide a "make dist"
>> target, fortunately there's this awesome tool called git, and it
>> provides a "git archive" command that does much the same thing. Did I
>> mention it's fast?
>>
>> Here are the performance numbers I see on a 2 core 4 thread SKL, without
>> initial configuration, and building out of tree (using zsh):
>>
>> For meson the command line is:
>> time (meson build -Dmanpages=true && ninja -C build)
>>
>> For autotools the command line is:
>> time (mdkir build && cd build && ../autotools && make -j5 -l4)<Paste>
>>
>> meson (cold ccache):     13.37s user 1.74s system 255% cpu  5.907 total
>> autotools (cold ccache): 26.50s user 1.71s system 129% cpu 21.835 total
>> meson (hot ccache):       2.13s user 0.39s system 154% cpu  1.633 total
>> autotools (hot ccache):  13.93s user 0.73s system 102% cpu 14.259 total
>>
>> That's ~4x faster for a cold build and ~10x faster for a hot build.
>>
>> For a make clean && make style build with a hot cache:
>> meson:     4.64s user 0.33s system 334% cpu 1.486 total
>> autotools: 7.93s user 0.32s system 167% cpu 4.920 total
>>
>> Why bother with libdrm?
>>
>> It's a simple build system, that could be completely (or mostly
>> completely) be ported in a very short time, and could serve as a tech
>> demo for the advantages of using meson to garner feedback for embarking
>> on a larger project, like mesa (which is what I'm planning to work on
>> next).
>>
>> tl;dr
>>
>> I wrote this as practice for porting Mesa, and figured I might as well
>> send it out since I wrote it.
>>
>> It is very likely that neither of these large patches will show up on the
>> mailing list, but this is available at my github:
>> https://github.com/dcbaker/libdrm wip/meson
>
>
> I guess I'm a little late to the party here, but I haven't had time to
> really let all of this sink in and actually look at meson.  It doesn't
> seem so bad with a quick look and I think I could probably sort it out
> when the time came, but there would still be a bit of a learning
> curve.  While that may not be a big deal at the micro level, I have
> concerns at the macro level.
>
> First, I'm concerned it may discourage casual developers and
> packagers.  autotools isn't great, but most people are familiar enough
> with it that they can get by.  Most people have enough knowledge of
> autotools that they can pretty easily diagnose a configuration based
> failure. There are a lot of resources for autotools.  I'm not sure
> that would be the case for meson.  Do we as a community feel we have
> enough meson experience to get people over the hump?  Anything that
> makes it harder for someone to try a new build or do a bisect is a big
> problem in my opinion.

Meson is so much nicer for the casual contributor than autoconf.  I've
been hacking at converting the X Server for two days, and I'm now far
more capable at meson than have ever been at autotools, and I've been
doing autotools for 15 years (I don't know how many autotools build
systems I've written over that time, but it's in the tens at least).

I think meson is a win for new users already.  I think we get into even
bigger wins when we consider the use of wrap when there's no distro copy
of a library -- just imagine never having to write instructions like the
"X Server" or "Mesa" parts of this page again:
https://github.com/anholt/mesa/wiki/VC4-complete-Raspbian-upgrade
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170322/0643def6/attachment.sig>