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

[Matt Turner]

On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> Seems like we ended up all over the place, so let me try afresh.
>
> Above all:
>  - Saying "I don't care" about your users is arrogant - let us _not_
> do that, please ?

Let's be honest, the OpenBSD is subjecting itself to some pretty
arbitrary restrictions caused including Mesa in its core: 10+ year old
GCC, non-GNU Make, and now no Meson. I don't believe either FreeBSD or
NetBSD keep Mesa as part of the core operating system, and as such
don't suffer from these problems.

For better or worse, they have made their choices and they get to live
with them. We are not beholden to them.

> Even Linux distribution maintainers have responded that "upstream does
> not care us", which is indicative that we should be more careful what
> we say.

Citation needed.

> For the rest - we're dealing with two orthogonal issues here:
>
> * Multiple build systems
> I believe we'll all agree that I might be the person who's been in all
> the build systems the most.
> Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:

No one is advocating dropping all of the existing build systems yet.

This patch is an RFC for a smaller project to start the discussion about Mesa.

>  - [currently] there is no viable solution for Android

Acknowledged. Dylan is going to see if this is something that can be
solved in upstream Meson.

>  - dropping the Autotools will lead to OpenBSD and NetBSD having to
> write one from scratch, IIRC Solaris/FreeBSD and others are in similar
> boat.

Solaris is a closed source operating system whose developers do not
contribute to the project. We do not need to base our decisions on
them.

Mesa is not subject to ridiculous requirements (like in the case of
OpenBSD) in FreeBSD and NetBSD. Mesa depends on gmake in FreeBSD's
ports, for instance.

So I don't think any of this is true.

> These projects have been getting closer to upstream and "forcing" the
> extra obstacle is effectively giving them the middle finger.

No. Requiring us to compile with a 10 year old GCC is giving a middle finger.

> * Slow build times
> Before we jump into "the next cool thing", let us properly utilise
> what we have at the moment.

It cannot be properly utilized. There is a patch on the list *today*
that is attempting to workaround the *design* of libtool. It's an
issue that's existed... since libtool?

https://bugzilla.redhat.com/show_bug.cgi?id=58664
https://lists.gnu.org/archive/html/libtool/2003-06/msg00068.html

>  - I've asked multiple times about numbers behind those "let's make
> the build faster" patches, but never got any :-\

What patches? The patches in this thread? What is your question?

>  - I can improve things but would need access to a fancy XX core
> system to do rudimentary benchmarks/checks and test patches.

Have you ever seen an autotools build system for a project as complex
as Mesa that is both non-recursive and comprehensible? I have not, and
I did a lot of searching. In my opinion, this is an intractable
problem.

... and with Meson it is tractable. And it doesn't use libtool. And it
can replace at least 2 and maybe all three of our build systems.

Those all seem extremely compelling to me, and I think I've done
enough work on Mesa's build system and on a downstream distribution to
have a valuable opinion on the matter.