On Mon, Mar 20, 2017 at 2:28 PM, Timothy Arceri <tarc...@itsqueeze.com> wrote:
> > > On 21/03/17 06:39, Emil Velikov wrote: > >> On 20 March 2017 at 18:30, Matt Turner <matts...@gmail.com> wrote: >> >>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.veli...@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. >> > We're not trying to "break things". The objective is to substantially simplify maintenance of our already very large and sprawling project. If the best way to do that ends up breaking something ancient, that's something we need to evaluate. However, "we're breaking X usecase" is not a slam-dunk argument against it either. > 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. >> > As is not having clang available when they build mesa. But we still take patches to keep it building on 4.2. > 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 ? >> > Yes. I pushed a patch just this last week to not use a compound initializer in a particular place because GCC 4.6 doesn't know that a compound initializer made entirely out of constant literals is a constant value. It works fine on moderately recent GCC but not on really old versions. If I could use compound initializers when declaring static constant things, it would make certain corners a bit nicer. I could come up with more examples. That's just the freshest. > 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. >> > If we can make building our project faster and have a build system that's way easier to maintain, why shouldn't we? Just because autotools is the thing everyone's been using since forever doesn't make it good nor does it mean it's the best choice for mesa. Let's actually evaluate our options.
_______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
