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

[Matt Turner]

On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> 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.

That is not even remotely the point.

My point is that they are not subjecting themselves (and us by
extension, since you want to let them) to such ridiculous
requirements.

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

Are you freaking serious?!

This happens *all* the time. It happened like two days ago with commit
28b134c75c1fa3b2aaa00dc168f0eca35ccd346d. I'm sure it probably
happened at least once in the previous month, and every month before
that.

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

We actually have

    if test "x$USE_GNU99" = xyes; then
        CFLAGS="$CFLAGS -std=gnu99"
    else
        CFLAGS="$CFLAGS -std=c99"
    fi

in configure.ac to work around gcc-4.4 incompatibilities.

> Not to mention that some/many of the restrictions are imposed by very
> older enterprise linuxes.

which eventually go out of support and those requirements disappear.
Unlike OpenBSD's insistence on using the last GPLv2 GCC.

>>> * 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 :-\

Because it's basically always small. The whole project needs to be
non-recursive, otherwise you get lots of little directories and stalls
(generating format_srgb comes to mind). All the work making things
non-recursive are opportunistic, and don't really address the
completely intractable nature of the problem: there are still 95
Makefile.ams.

> 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 :-\

Just looked -- you know what their last commit to Makefile.am is?

    Makefile: Drop vestiges of support for non-GNU Make.



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

Troll bait.

> It is far from perfect, yet we can improve things on our end rather
> than throwing everything in the bin.

I have. Again, I think I have done enough of that that I have some
credibility on the matter.