[Mesa-dev] Lets talk about autotools

[Matt Turner]

On Fri, Sep 21, 2018 at 11:38 AM Emil Velikov <emil.l.velikov at gmail.com> wrote:
>
> On 20 September 2018 at 19:19, Dylan Baker <dylan at pnwbakers.com> wrote:
> > Quoting Eric Engestrom (2018-09-20 07:56:45)
> >> On Thursday, 2018-09-20 15:28:09 +0100, Emil Velikov wrote:
> >> > Hi Chuck,
> >> >
> >> > On 18 September 2018 at 16:00, Chuck Atkins <chuck.atkins at kitware.com> wrote:
> >> > > First, I'm fully in support of killing off autotools woo-hoo to that.  And
> >> > > given the substantial investment already put into the meson build that
> >> > > certainly seems like a good direction to go.
> >> > >
> >> > > That being said, the way "auto" is currently implemented leaves quite a bit
> >> > > to be desired.  One of the nice features of the Autotools build was how
> >> > > auto-enabled options were treated in that the dependencies were searched for
> >> > > and if they were all found and met then the option would be enabled.  My
> >> > > experience so far with the meson build has shown this not to be the case and
> >> > > a "configure" with no options has yet to be successful for me.  Many of the
> >> > > 'auto' options are treated as 'set to true if your platform supports it'
> >> > > regardless of whether your system has the requisite dependencies available.
> >> > > For example"
> >> > >
> >> > > The 'gallium-va' option defaults to 'auto' but the implementation ends up
> >> > > setting the '_va' option to true if the other option conditions are met,
> >> > > long before libva is searched for.  So then when libva isn't found one gets
> >> > > an error.
> >> > >
> >> > > if set to auto then missing the libva dependencies should be a failure, it
> >> > > should just disable the gallium va state tracker
> >> > >
> >> > > The platform options set to 'auto'  has a set of checks to determine which
> >> > > platforms are enabled as required.  If the system_has_kms_drm check is true
> >> > > then Wayland is enabled as required.  Later if the check for wayland
> >> > > dependencies fails, an error occurs.
> >> > >
> >> > > If platforms are set to auto then a failure to locate dependencies for a
> >> > > given platform should disable the platform.
> >> > >
> >> > > I realize these are just two specific examples, each of which can be readily
> >> > > dealt with in their own specific way so I'm not asking "how to I address #1
> >> > > and #2?" because I can certainly do that.  These are just two instances of
> >> > > many though in the way "auto" is dealt with.  My point is really a broader
> >> > > one that before meson becomes the primary build then the behavior of "auto"
> >> > > should create a successful configure out of the box without additional
> >> > > options.
> >> > >
> >> > I would like to revive an idea from a few years ago:
> >> > Drop the "auto" all-together.
> >> >
> >> > It adds a _ton_ of complexity while making the build semi-magical/not
> >> > as deterministic.
> >> > IIRC the Gnome people have been actively working for removing such
> >> > autodetection in their packages.
> >> >
> >> > The only downside is that we may need to tweak our scripts _once_ to
> >> > list exactly what we want to build ;-)
> >>
> >> _Once_ for you, because you have everything already set up, but for all
> >> the new users this means that nothing will work out of the box, they'll
> >> need to understand each and every options and figure out what they need
> >> them set to, before they can even start.
> >>
> >> That sounds like a huge step backwards to me :/
> >
> > Especially when one of the explicit goals was to support 4 OS families
> > (Unix-like, windows, mac, haiku). To make that all work out of the box we'd end
> > up building *nothing* by default.
> >
> As mentioned elsewhere - if you don't know what you're doing (it's
> fine to admit that), simply follow your distribution.
> If you do not trust your distribution ... well. Otherwise - read.

This would generate so many unnecessary support requests. I argued for
the same thing years ago, and I've come to agree that automatically
picking sane defaults is the best solution for everyone, users and
developers alike (for different reasons).