Quoting Emil Velikov (2018-12-03 10:25:48) > On Mon, 3 Dec 2018 at 17:49, Dylan Baker <dy...@pnwbakers.com> wrote: > > > > Quoting Emil Velikov (2018-12-03 07:54:38) > > > Hi all, > > > > > > On Thu, 29 Nov 2018 at 17:44, Emil Velikov <emil.l.veli...@gmail.com> > > > wrote: > > > > > > > > Hi all, > > > > > > > > I can see why people may opt to not use or maintain the autotools build. > > > > Although I would kindly ask that we do not remove it just yet. > > > > > > > > In Mesa, we have different parts not used by different teams. As such > > > > we tend to remove stuff when nobody is around to maintain it anymore. > > > > > > > > That said, I'm planning to continue maintaining it and would appreciate > > > > if we keep it in-tree. > > > > > > > > As people may be concerned about bugreports and alike we can trivially > > > > add a warning (as configure is invoked) to forwards any issues to my > > > > email. Additionally (or alternatively) we can have an autotools bugzilla > > > > category with me as the default assignee. > > > > > > > > > > Seems like I failed to make things clear enough with earlier message. > > > > > > There is _no_ expectation for anyone to touch or even look at autotools. > > > Hence, my suggestion to have configure.ac point people to me in case of > > > issues. > > > > > > If people have CI that uses it - feel free to drop it. > > > > > > > I've tried to stay out of this discussion, because everyone knows my > > opinion, > > and I feel I don't have much to add, however... > > > > > > > > That said, many have asked why I'd go through the pain of maintaining it: > > > - Most Linux distributions have switched, but there'still a few > > > outstanding > > > - Non Linux distributions have not switched > > > > Haiku has at least :) > > > \o/ > > > > - The meson build is missing features, relative the autotools one > > > > The only feature that I know that meson does not have relative to autotools > > is > > the gl mangling stuff (which is intentional, we'll add it if someone shows > > up > > with a need for it). Everything else is either intentionally not implemented > > (GLX TLS toggling for example, which meson hardcodes on for OSes that > > support > > it, and off for those that don't). > > > On top of the TLS and symbol mangling (for which I agree) there is: > > - no CrOS support
We've done the best we can to get chromeos running (all of the "android") stuff is actually for chrome's android container. I've also fixed a number of meson bugs for them, if there's more they need from us they need to let us know. It's unfortunate that I don't have good contacts with Chrome people and Intel anymore :/ > - static/shared mesa (or at least parts of) - Kitware guys are still using it No one has brought this up, this is actually the thing on the list I'm most reluctant to enable, mostly because I don't understand the use case for building OpenGL static, and there would be a lot of validation required to make sure everything works correctly. > - non-static gallium targets - yes it's intentionally 'hidden' in > configure.ac I'm happy to turn this on if there's a use case and someone who wants to maintain and support this. My understanding was that there was a lot resistance to use this feature as VMware didn't want this on windows and everyone else was reluctant to add another "windows vs !windows" path. > - disable direct glx - non linux people use this This is another one of those we'll add when someone asks, like the mangling stuff. There were a number of features that when I started I asked about and the consensus was "wait and see", if anyone needs it we'll add it. > > I understand the reluctance on the latter two, yet leaving CrOS and > Kitware in the cold seems strange. > > > > - I've been approached by individuals, who cannot quite yet use meson > > > > At this point we've been very clear of our intentions to move to meson, as > > Matt > > said I have worked very hard to resolve any issues developers and users > > have had > > (and have spent a lot of time booting VM's and fixing meson and mesa's meson > > build on non-linux OSes) or reported, but we can't resolve issues that > > aren't > > reported. If people are having issues using meson and they're not filing a > > bug > > with meson or with mesa, or mailing the list, or getting on IRC, there is > > nothing we can do for them, and at some point they need to speak up, or > > accept > > things. > > > As the Mesa community grows, the amount of discussions/patches we > produce is quite intimidating. This is a good point. Dylan > Over the years, I've been reaching out to distributions and > maintainers, many of which doing this as a hobby, to ease their mind. > > Your point is valid - issues should be brought forward. Although > without encouragement things are hard sometimes. > > Thanks > -Emil
signature.asc
Description: signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
