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 ;-)
> 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 ? 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. >> * 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. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
