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

[Emil Velikov]

On 20 March 2017 at 18:30, Matt Turner <mattst88 at gmail.com> wrote:
> 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,
IIRC Brian was using old MinGW GCC, which was one of the blockers - it
wasn't OpenBSD to blame here ;-)

> 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.
>
Overall this hunk seems misplaced. I go agree that we should not cater
for all their needs. At the same time, intentionally, breaking things
while we all can coexist is very strange.

>> 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.
>
https://bugs.freedesktop.org/show_bug.cgi?id=98487#c4 and there's a
couple of instances where I've been contacted in private.

>> 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.
>
I would suggest checking with Android people as well, as Meson.
There's some plans on moving to yet another build system - Blueprint.

>>  - 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.
Again - not a requirement, but coexistence.

> Mesa depends on gmake in FreeBSD's
> ports, for instance.
>
That amongst others is a bug in their packaging.

> So I don't think any of this is true.
>
I'd suggest giving it a try then - grab a non-GNU make, a release
tarball and let me know if you spot any issues.

>> 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.
>
Can we stop with the GCC thing ? Can we point to a place where we want
to use feature A introduced with GCC B and we don't ?

The anonymous unions/structs for example require newer GCC and we use
them extensively. If anything we have the workaround(s) for MSVC's
lack of designated initializers.
Not to mention that some/many of the restrictions are imposed by very
older enterprise linuxes.

>> * 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
>
Yes design is ..., but I'm talking about utilising all the X cores on $platform.

>>  - 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?
>
Nearly every time we had a "let's remove this recursive Makefile"
patch I asked "what improvement are we talking about here - how long
does it take before/after this patch to build mesa".
I'm yet to see any numbers :-\

Some cases that come to mind - mapi (gles1/2), glsl, nir and the latest ANV.

>>  - 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.
>
Haven't looked at all really - off the top of my head openvswitch comes to mind.
Then again, It's not as extensive as mesa :-\

> ... 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.
Yes you did a lot of work on the autotools side, with less so on scons
and android.

What I'm saying is - let us be mature and stop it with the [reasonable
or not] hatred towards autotools.
It is far from perfect, yet we can improve things on our end rather
than throwing everything in the bin.

-Emil
P.S. Last I've looked Meson does not have a dist/distcheck target, not
sure about more exotic ones like cscope and friends.