[Mesa-dev] Lets talk about autotools

[Eric Engestrom]

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 :/

> Distributions already explicitly specify what they want and most of
> our autodetection is effectively a bad copy of that.
> 
> HTH
> Emil