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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
