[Mesa-dev] Suggestions for improving meson-based builds

[Ilia Mirkin]

Hello all,

There has been some discussion of late about dropping autotools or
making it a second-class citizen. I firmly believe such discussions
are premature.

I've had a chance to try meson recently. First off, I'd like to
commend the meson team (both the core project as well as the mesa
developers who have been pushing it) for being responsive to
build-prevention concerns (e.g. "the build doesn't work"). It does now
build successfully for me, which it did not when these efforts were
starting out.

In those tests, however, I noticed some shortcomings, which I believe
require being addressed before meson can be used in a major project
such as mesa. I'd like to outline some bits that any autotools
replacement needs to have (be it meson or anything else), in order to
be viable. This is all obviously on top of "produce correct build
results", which I take as a given. These are mostly in order that they
happened to occur to me rather than  prioritized by importance.

1. Build creation command recovery. With autotools, "head config.log"
will tell you how you configured it. This is important when things get
screwed up, and so has to be available in plain text somewhere. There
are a variety of other occasions where this can be useful -- debugging
someone else's build, creating a second build for yourself with a few
options changed, etc.

2. Summary at the end. This is not strictly an autotools-specific
issue, but rather how mesa has used it. That summary at the end is
very useful to make sure you (or someone you're helping) hasn't
screwed something up.

3. Have a configure helper which makes it look like autotools.
Everyone knows how to use autotools, in part because it's so very easy
to use. No one wants to figure out how to operate some random
project's build system (and while meson may have world-dominating
aspirations, it's certainly not there yet). This is one of the reasons
I avoid doing anything of substance with cmake-based projects. A few
bits which ought to work: "./configure --help", "./configure
--with-gallium-drivers=..." and so on, similar to the existing logic,
"./configure CFLAGS=-O0" and so on. Those environment variables need
to be baked into the build, and it should be able to bake in things
like PKG_CONFIG_PATH in a way that affects meson's operations, not
just the build-time bits. This should default to a particular build
directory (perhaps creatively called "build"), with some way to
specify an alternate (e.g. add a --builddir=...). I think it's fine to
have a dummy Makefile generated in this case which just says "run
ninja" without actually running it.

4. No matter what happens to the system, re-running "ninja" or
"configure" should not cause failures. This can't always be prevented
(bugs happen, I get it), but you get like one screwup every 5 years --
it should be avoided as much as possible. If the solution is that the
tool re-runs itself using the old configuration, that's fine -- but it
can't just die saying "oh no, you're screwed", which it currently does
when updating meson on the system.

5. Cross-files are a clever way of solving the issue by offloading it
as "not-my-problem". And the configuration for cross-compiling project
A is going to be identical to project B. I understand all this.
However in declaring it as "not-my-problem", meson makes it the user's
problem. These files are currently not shipped as part of
cross-compiling setups, and asking each user to figure out how to set
them up is excessive -- cross builds are complex enough, and this is
yet-another thing in the path to success. The configure wrapper should
be able to take the standard parameters (--build, --host, etc) and
have it work (e.g. by generating a cross-file on the fly).

Some of you reading who have made it this far (congratulations!) might
be thinking that all this "make meson look like autoconf" is just
silliness from someone who doesn't want to adapt to some new thing.
You're right - it is. But I don't think I'm alone. To those who are
looking for builds to be faster, you'll still get all your improvement
from having improved speed/caching of system settings and ninja's
improved parallelism. To the casual user, mesa will look like any
other project that doesn't require additional hoops to jump through.

Like it or not, autotools is currently the standard. The current
in-tree meson proposal is trying to change too much at once.

Cheers,

  -ilia