Porting Mesa/Libdrm's Build System To Meson Brings Up Controversy

[phoronix]

Phoronix: Porting Mesa/Libdrm's Build System To Meson Brings Up Controversy

Last week an independent developer proposed replacing the build system of libdrm -- the DRM library that sits between Mesa and the Linux kernel DRM -- to using the Meson build system as a potential replacement to using Autotools. That has led to another colorful discussion around build systems...

http://www.phoronix.com/scan.php?page=news_item&px=libdrm-Meson-Discussion

[OlafLostViking]

phoronix: Meson is an alternative to CMake, Ninja to Make.

[shmerl]

CMake + Ninja is probably a better idea.

[emblemparade]

Ninja in itself is not significantly faster than Make (and Meson definitely isn't). It's just that Ninja is multithreaded by default, whereas in Make you need to turn that feature on explicitly using -j. It's main advantage over Make is that it's very straightforward and minimalist, meaning less room for bugs. But it also means that you probably want a frontend for Ninja to add the features you need. That's what Meson is.

Shameless self promotion: I have a lot of problems with Meson's architecture, and so created a different frontend for Ninja, called Rōnin.

[shmerl]

@emblemparade: CMake also works a frontend for Ninja. I didn't know it's already used in Mesa. I thought it's pure autotools / make.

[Marc Driftmeyer]

Just use Cmake. It has thousands of already flushed out examples to work and draw upon to build and refine the CMakelists

[emblemparade]

@emblemparade: CMake also works a frontend for Ninja.

That is correct. However, I wonder how useful that combination would really be? If you've decided to use CMake, you really don't have to worry about the engine used at the far end, whether it's Make or Ninja. Since performance is pretty much equal for them, it seems like a better bet to go with Make, due to its maturity and ubiquity.

Tools like Rōnin, Meson, Craftr, pyrate, etc., are designed specifically with Ninja in mind, so they tend to be far more minimal than CMake. (And they have the advantage/disadvantage of using Python as their build script language.)

[yoshi314]

meson is great because it's very simple wrt to its makefiles syntax. i personally hope it does take off, at least as secondary supported build system.

autotools suffer from the problem of requiring to learn multiple different things. i do not know about cmake, it definitely looks cleaner, but it seems like actual syntax is outgrowing the actual content.

[oleid]

Using existing cmake projects as subprojects is a pain, if those are not designed to support that. It seems as meson can handle that just fine, can't it? So +1 for meson.

[leio]

That is correct. However, I wonder how useful that combination would really be? If you've decided to use CMake, you really don't have to worry about the engine used at the far end, whether it's Make or Ninja. Since performance is pretty much equal for them, it seems like a better bet to go with Make, due to its maturity and ubiquity.

I'm told CMake ninja backend generates rather awful ninja files, unlike meson.

Tools like Rōnin, Meson, Craftr, pyrate, etc., are designed specifically with Ninja in mind, so they tend to be far more minimal than CMake. (And they have the advantage/disadvantage of using Python as their build script language.)

Meson does not use Python as its build script language. The build scripts are not Turing complete and they are not Python. This is considered an advantage. Meson itself is just (currently) written in python3 standard modules (no extra python packages used) and needs ninja and nothing else. Someone could go rewrite it (or provide an alternative implementation) in Rust or C or whatever, but the consumers would continue working if done properly. It seems to take all the previous experiences into account and come up with something that learns from them all.