Mesa Developers Move Closer To Dropping Autotools Build System In Favor Of Meson

[cl333r]

I have to say this, Rust's cargo beats all C/C++ build systems.

[Redfoxmoon]

It's not just about performance. It's simple to use, easy to read and write. Even if Autotools supported Ninja and Meson didn't, I would choose Meson.

Autoconf syntax is easy to understand, automake not only makes make(1) less gritty, but it also makes simpler projects dead easy to support

[cen1]

Autotools should die in fire. CMake and I guess Meson if you really insist is the way to go.

[kpedersen]

I really never liked autotools. It is basically a sprawling mess.

I would have preferred Mesa choose a standard build system like CMake rather than a niche one but any choice is still better than Autotools.

My problem is that in 10 years, it is likely going to be awkward to run meson itself (because the world would have moved on to Python 4), let alone use it to build Mesa. A build tool written in C or C++ is always more maintainable.

[Redfoxmoon]

I really never liked autotools. It is basically a sprawling mess.

I would have preferred Mesa choose a standard build system like CMake rather than a niche one but any choice is still better than Autotools.

My problem is that in 10 years, it is likely going to be awkward to run meson itself (because the world would have moved on to Python 4), let alone use it to build Mesa. A build tool written in C or C++ is always more maintainable.

That depends on whether or not python implodes before that happens. Personally I hope it does.

[miabrahams]

My problem is that in 10 years, it is likely going to be awkward to run meson itself (because the world would have moved on to Python 4)

Although the Meson build files use a Python inspired syntax, they are not evaluated by the Python interpreter. Porting to Python 4 would be no more of a challenge for Meson than it would be for any other Python package.

[nanonyme]

The only thing I'm worried is keeping Meson bootstrappable. If let's say Python moved to use Meson, that might turn a lot harder

[skeevy420]

I have to say this, Rust's cargo beats all C/C++ build systems.

Rust, while hard to learn IMHO, does a lot of things that make it easier for people wanting to learn. Cargo containing everything related to the project, rustup to switch compiler version branches, cross-compile, etc. If you're new to programming, having all of that available as standard tools of the programming language is really nice.

There's no having to learn some random language while also learning an unrelated random build system; nope, with Rust it's all one integrated family that works cross platform. Find a good cross platform editor or IDE and you can work on your project for whatever platform from any OS, any platform.

[discordian]

Although the Meson build files use a Python inspired syntax, they are not evaluated by the Python interpreter. Porting to Python 4 would be no more of a challenge for Meson than it would be for any other Python package.

Does meson allow you to write re-usable scripts for inclusion in multiple projects?
At the time when I explored different build systems, the only choice was either to call python scripts (or other languages, but the argument was at that time to use python as this will be available when meson is). Or to get your functionality upstream (which again, is python code).

compare that to CMake or Autotools which use their own scripting languages - those core tools could e re-implemented with any language without any of the custom modules or extensions being affected. With Meson you have to port every functionality, except the DSL files.

My CMake scripts can be butt-ugly but I am sure they will work will the end of time, as CMake is incredible pedantic when it comes to that (see their policies). I am also not sure if Meson will ever support the coming C++ Modules correctly, thats a big question for CMake aswell but Mesons response seems that the standard needs to bow to their needs ( https://github.com/mesonbuild/meson/issues/4314 ).

Just because I could not ask for a clearer statement.

Meson dev (later wrote the "remember the fortran" paper):

The tl/dr version is that the model as currently defined does the same thing as FORTRAN, which is a nightmare to support in a build system.

CMake ( https://gitlab.kitware.com/cmake/cmake/issues/18355 ):

To give you an idea of the amount of shall we say, nonsense, going on here, we can look at the last "remember the fortran" paper which claims that both:

1) Fortran modules work almost exactly like the proposed CPP modules (which supports my posts), and
2) No one in computer science has discovered how to compile Fortran modules. Absolutely no one. Certainly not CMake, which compiles Fortran modules correctly every time.

[FireBurn]

Try cross compiling a package, also it is so amazing, that libinput additionally needs ninja or so, ..! and then you have already to deal wit two annoying build "tools" – plus each build system has other --enable-some-feature option and such. The libinput build is so hilarious now, that I will probably make a dedicated video documenting this mess sometime soon. No wonder that desktop Linux is not progressing, if half of the time is spend re-implementing the build system of each package that already worked for for a decade or more.

I've been cross compiling Mesa since March using Meson