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

[Alex Deucher]

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.

Next, my bigger concern is for distro and casual packagers and people
that maintain large build systems with lots of existing custom
configurations.  Changing from autotools would basically require many
of these existing tools and systems to be rewritten and then deal with
the debugging and fall out from that.  The potential decreased build
time is a nice bonus, but frankly a lot of people/companies have years
of investment in existing tools.

my 2 cents.

Alex