[Mesa-dev] Lets talk about autotools

[Mathieu Bridon]

On Thu, 2018-09-20 at 15:56 +0100, Eric Engestrom wrote:
> 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 :/

Meson has a great feature called… "features".

The way it works is you have options which can be either enabled,
disabled or "auto".

This way, those optional parts of the build can be built automatically
by default if the required dependencies are present, or skipped if not,
which seems to be what you want.

However, meson then has a --auto-features option which allows build
integrators to get deterministic, reproducible builds by removing the
automatic enabling/disabling based on dependencies.

Which seems like it can reconcile what you and Emil want? :)

More details here:

http://mesonbuild.com/Build-options.html#features

As a build integrator myself at the Freedesktop SDK project, I would
love Mesa to make good use of this.

We regularly have issues due to this automatic behaviour, because we
forgot a dependency or added one by mistake.


-- 
Mathieu