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

[Timothy Arceri]

On 21/03/17 06:39, Emil Velikov 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 ;-)

Sorry Emil I probably wasn't clear in our discussion. I sent out patches 
to switch to GCC 4.8 last Sept (I believe this was needed by RHEL6) [1].

Brain jumped in and said "I'm still using the MinGW gcc 4.6 compiler. 
I'd rather not go through the upgrade hassle if I don't have to."

Followed by Jose "We're internally building and shipping Mesa compiled 
with GCC 4.4 (more specifically 4.4.3).

It's fine if you require GCC 4.8 on automake, but please leave support
for GCC 4.4.x in SCons."

By this point I got bored and moved on. But OpenBSDs GCC is a fork with 
various features backported, from what I understand Mesa would not build 
on a real GCC 4.2 release and we should not be using it as a min 
version. IMO if OpenBSD want to maintain a GCC fork they can handle a 
patch to downgrade the min GCC version.

I believe Jonathan would like us to stick with 4.2 as min but is 
prepared to deal with it if we move on.

[1] https://patchwork.freedesktop.org/patch/109094/

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

I think you are missing the point, no-one wants to (should have to) look 
up if features X was in GCC stone-age every-time they want to use 
something. Also as I pointed out when discussing the Zlib min version, 
we should be recommending min versions that are actually regularly 
tested with Mesa. Frankenstein RHEL 6 and OpenBSD libs and tools with 
significant backports should be left to the distros to sort out and do 
their own qa testing/lowering of min versions recommended by Mesa.

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

??? I don't think we do. RHEL 6 is the oldest distro that actually ships 
new version of Mesa and if that were the only concern we could have 
bumped to GCC 4.8 already.

>
>>> * 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.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>