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

Tue Mar 21 17:16:20 UTC 2017

On 21 March 2017 at 15:57, Matt Turner <mattst88 at gmail.com> wrote:
> 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.
>
I will kindly ask you to keep these adjectives outside of what aims to
be (?) technical discussion.

And on your question - 50-100 lines worth of compatibility changes
across a 6.5kloc of build system is not that unreasonable, right ?

>>> 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.
>
Considering none of the ANV code is built outside of Linux, why you
guys will restrict yourself is beyond me.
Nine requires GCC 4.6 and Clover GCC 4.7 for a long time.

>> 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.
>
5-10 lines of configure code is not that much of a burden, right ?

>> 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.
>
At which point we can reconsider, right - perhaps they have the
functionality backported, have moved to new version/another compiler
etc.

>>>> * 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.
IIRC Jason, mentioned something similar to "loads" with the recent ANV
move - silly me cannot find the quote :-\

Found another one though (from the glsl/nir move to compiler/)

On 16 December 2015 at 20:24, Matt Turner <mattst88 at gmail.com> wrote:
> On Wed, Dec 16, 2015 at 8:53 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:

> > Can anyone confirm how much of a penalty are we talking about (single
> > vs separate makefiles) ?
>
> I'm not going to take the time to quantify it. Just do a clean build
> and watch as 7 of your 8 cores sit idle as format_srgb.c is generated
> or shared-glapi/libglapi.la is linked. (A dual-core system is not
> going to demonstrate this issue properly)

This is where I should have said - "I don't have a 8 core system, so I
cannot measure it", although on your end one could have let it compile
[say, during your lunch] and share with some numbers.
Your reply is quite provocative and even if I've had an full-retard
moment, I'm not sure that this is the way to reply.

> 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.
>
Fully agree - those can be reworked, but I simply cannot measure any
difference on the systems I have access to.
Hence, cannot estimate the severity of the problem.

>> 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.
>
That's their decision. I am pointing out that one can have a sane
project w/o recursive makefiles, yet perfectly readable.

>>> ... 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.
>
? You're saying that nobody is bashing on autotools/friends... ok.

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

Not trying to belittle any of your work, but this does not parse in
reply to my suggestion, sorry.

Overall your replies seem quite spontaneous/emotional. If I'm making
you upset - I do apologise.
I'm simply trying to get as much technical details, which I seems to
be tailing at.

-Emil