On 21/03/17 06:39, Emil Velikov wrote:

On 20 March 2017 at 18:30, Matt Turner <mattst88@gmail.com> wrote:

On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.velikov@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.