[Mesa-dev] Lets talk about autotools

[Dylan Baker]

Quoting Emil Velikov (2018-12-03 10:25:48)
> On Mon, 3 Dec 2018 at 17:49, Dylan Baker <dylan at 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.velikov at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20181203/2c163f5f/attachment-0001.sig>