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

[Jason Ekstrand]

On Sun, Dec 16, 2018 at 1:49 PM Ilia Mirkin <imirkin at alum.mit.edu> wrote:

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

I'm not sure that this is necessary but I agree that it is useful.  I think
Dylan said someone was working on this?


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

Run "meson configure" with no options.  It will dump out a full
configuration.  Sure, it's not the same format but, unless I'm
misunderstanding something, all of the information from the old summary and
more is available there.  Or are you concerned with various derived or
auto-configured values?  Or is it your concern that it get dumped out at
the end of a configure rather than having to ask for it?  It'd be helpful
if you'd be more specific about what you want than "the autotools thing".


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

On the surface, I think this is a bad idea.  We currently have two build
systems that duplicate all these options and information and you're
effectively asking for a third.  Perhaps we could write a bit of python
which autogenerates it from meson_options.txt in which case it might be
ok.  However, I'm not at all a fan of duplicating all the information in a
shell script just so people can run ./configure instead of calling meson
directly.

For whatever it's worth, I used to also think this would be a good idea.
More recently, however, I've come to the conclusion that it'd just be a
crutch to help people continue pretending meson doesn't exist.  If we
provide ./configure and Make what are people going to want next?  In-tree
builds?  Also, when are we going to get to delete the ./configure script?
Probably never.


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

Yes,I agree that this is a failing of meson and needs to be sorted.  Meson
could do a much better job of reconfiguring by itself when it detects an
incompatible 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).
>

I have seen multiple times now people vastly over-simplify how "automatic"
autotools makes cross-building.  The crossfile contains a lot more than
just --build and --host; it has actual paths to compilers and pkg-config,
extra options, and a few other things.  Then how does autotools make it so
simple?  Because distros ship patched versions of autotools with the
distro-specific bits hacked in.  On Fedora, for instance, they've hacked it
up so that --prefix=/usr on a 64-bit system automatically implies
--libdir=/usr/lib64 even though libdir is usually ${prefix}/lib.  Where you
find the gcc compiler for ppcle64 on a x86_64 system, for instance, is also
highly distro-specific and requires patching.  The "correct" solution here
is for each distro, when they package meson, to also package a set of
appropriate cross files that instructs meson how to cross build for each
platform on that distro.  They should be easy enough to generate with a
tiny bit of python, perl, or shell code that's aware of how the distro lays
things out on the file system but it has to be done by the distro, not
meson.

This also means that your suggestion of just making the ./configure wrapper
generate the cross file isn't really all that practical.  I suppose you
could, in theory, have a script which attempts to auto-detect it by
crawling the file system and tries to find the compilers etc. based on
known distros.  However, any such attempt would be complicated, fragile,
and have unpredictable error modes when some unknown distro is encountered.

Sorry if I don't buy the "just make it look like autotools" argument.  With
X, Wayland, Weston, systemd, and many other system-level Linux projects
moving to meson, it may not yet be mainstream but I don't think it's
ignorable anymore.

--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20181216/f08a3bbb/attachment.html>