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

[Dylan Baker]

Quoting Ilia Mirkin (2018-12-16 11:48:52)
> 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.

There is (as of 0.49.0) a file called $builddir/meson-private/cmd_line.txt, it's
an ini file, but it does contain each option in a key value format. After dave
asked for a way to get the command line back, we've discussed replacing this
with having meson generate a native file that could be read in using the normal
--native-file option (which would make it super trivial to reuse)

> 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.

I personally really don't like this, I never want to read it, but a lot of
people have asked for it. Gstreamer apparently wants this as well, and there's
an opened issue I'll assign to myself:

https://github.com/mesonbuild/meson/issues/757

> 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.

As of 0.49 this should be *much* better. We now officially support upgrading to
the next version, meson will simply wipe the directory and start over with the
same options. It's certainly not optimal, especially if you're not using ccache,
but it will update.

> 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
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- 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/20181217/da21fdec/attachment.sig>