Libinput 1.8 Switches To Meson As Its Primary Build System

[carewolf]

Nope, it wasn't. Jussi Pakkanen is a CMake user, and created Meson to fix the issues that CMake has — bolted on Turing-completeness of the DSL; obscure error handling; weird and incomplete cross-compilation support; bizarre dependency discovery based on copy-pasting random files; etc.

Jussi is on Planet GNOME, and has been invited to speak to GUADEC, but I wouldn't characterise him as a GNOME developer.

GNOME maintainers are just picking it up because Meson is clean, lean, and fast, and well-integrated with all the tooling GNOME already uses — internationalisation, code generation, help and API documentation. The option would be to mess around with CMake, which has none of those things and would require writing them from scratch.

So it is associate to GNOME the same way CMake is associated with KDE? They are early adopters and thus all the early tooling mainly benefits them.

[zoomblab]

I took a brief look into meson and IMHO I see no benefit over CMake. Actually most meson build files I see so far are horrendous sheets of code full of conditionals and loops and zero consistency and standardization. Of cource for the poor souls still suffering with autotools to this day even this is a major improvement. However, having been spoiled with the brilliant build tools in the Java ecosystem I am waiting for something with at least similar qualities, namely:

• Declarative instead of imperative style
• Convention over configuration
• Standardized project structure
• Project object model
• Built in dependency management
• Build lifecycle management
• Single artifact per module
• and so on ..

Meson supports none of that.

[bug77]

I took a brief look into meson and IMHO I see no benefit over CMake. Actually most meson build files I see so far are horrendous sheets of code full of conditionals and loops and zero consistency and standardization. Of cource for the poor souls still suffering with autotools to this day even this is a major improvement. However, having been spoiled with the brilliant build tools in the Java ecosystem I am waiting for something with at least similar qualities, namely:

• Declarative instead of imperative style
• Convention over configuration
• Standardized project structure
• Project object model
• Built in dependency management
• Build lifecycle management
• Single artifact per module
• and so on ..

Meson supports none of that.

You're describing Maven here, but Gradle is even better You won't believe the crap I've seen people shoved onto Maven and complained the build system is not flexible enough...

Also, from the link posted earlier:

However note that Meson places limitations on how you lay out your code.
...snip...

• all Java files must be in paths specified by their package, e.g. a class called com.example.Something must be in a Java file situated at com/example/Something.java

They haven't figured out that's a Java convention/requirement, not a build system limitation.

[bkor]

I took a brief look into meson and IMHO I see no benefit over CMake.

Meson has clear benefits over CMake. It integrates way better with various tooling. This has been said before by ebassi, so unsure why you ignore this. It is _the_ reason it is being adopted.

Do you have examples for what you consider a better build system? You gave examples of build files and IMO they look just fine. A lot of the things you mention appear to be "bullshit bingo". E.g. "artifact": wtf? Build lifecycle management: could mean anything. Etc. It's entirely vague.

[doom_Oo7]

CMake is not de-facto standard. It's used a lot by Qt/KDE; there's way more projects than that. The de-facto standard is autotools.

Maybe ten years ago, but not today. On github only there seems to be much much more projects using CMake than autotools.

Here's the search I've tried doing if someone wants to improve on it :

* autotools: https://github.com/search?utf8=%E2%9...dvsearch&l=&l=
* cmake: https://github.com/search?utf8=%E2%9...Atxt&type=Code

[Vistaus]

Maybe ten years ago, but not today. On github only there seems to be much much more projects using CMake than autotools.

Here's the search I've tried doing if someone wants to improve on it :

* autotools: https://github.com/search?utf8=%E2%9...dvsearch&l=&l=
* cmake: https://github.com/search?utf8=%E2%9...Atxt&type=Code

But Meson is picking up steam though. GNOME is switching to it, even GNOME projects are switching to it. Quite a few other popular projects are also switching to it, like Geary (they will switch from CMake to Meson as explained on page 1 of this thread), Corebird has added Meson support and the goal is to eventually switch to it, Budgie uses Meson... Outside of GitHub a lot of projects still use autotools. So while CMake might be popular, it's NOT the de-facto standard.

[bug77]

In my experience, one solution to rule them all is not the way to go. It just grows stale. Having two competing solutions, they will at least try to differentiate, add new features, copy from each other and such. It's a much more vibrant environment.

So yes, it would be nice if Meson introduced a paradigm shift, but I'm ok with a CMake lookalike, too.

[zoomblab]

Do you have examples for what you consider a better build system? You gave examples of build files and IMO they look just fine. A lot of the things you mention appear to be "bullshit bingo". E.g. "artifact": wtf? Build lifecycle management: could mean anything. Etc. It's entirely vague.

Bullshit bingo? The things I wrote are simply the core architecture principles of Maven, the most widely used build system in the Java ecosystem. Maven replaced legacy build systems (Ant, Make) that were similar to Meson and CMake, imperative script languages that allowed every single project to do whatever it thought cool. Maven brought a completely different idea of how a build system should work (all the things I mentioned) and changed everything for the better.

This is how a build file should look. Do you see that? Dependencies management. Single produced artifact per module. Only declarations. Not a single line of imperative code - they are not needed because of the standardized project structure. That and much much more.

I suggest to educate your self on the subject. It might help you to speak less nonsense.

[ebassi]

Bullshit bingo? The things I wrote are simply the core architecture principles of Maven, the most widely used build system in the Java ecosystem. Maven replaced legacy build systems (Ant, Make) that were similar to Meson and CMake, imperative script languages that allowed every single project to do whatever it thought cool. Maven brought a completely different idea of how a build system should work (all the things I mentioned) and changed everything for the better.

It's easy to introduce purely declarative builds, if you're only targeting a single language and an abstracted OS. Sadly, for everyone else using different languages (in some cases at the same time) and different OSes (at the same time, even, when cross-compiling), you still need to deal with conditionals and loops.

Luckily, Meson's DSL is not Turing-complete; you only deal with read-only objects, and you cannot create infinite loops. You cannot even glob file lists. It's probably the closest you can get to a generic purpose build system — like Autotools and CMake — while retaining a flat, declarative style.

It's all fine and dandy that Java got its XML-based build description language. The world out there doesn't all run on Java, though.

[bug77]

It's easy to introduce purely declarative builds, if you're only targeting a single language and an abstracted OS. Sadly, for everyone else using different languages (in some cases at the same time) and different OSes (at the same time, even, when cross-compiling), you still need to deal with conditionals and loops.

Luckily, Meson's DSL is not Turing-complete; you only deal with read-only objects, and you cannot create infinite loops. You cannot even glob file lists. It's probably the closest you can get to a generic purpose build system — like Autotools and CMake — while retaining a flat, declarative style.

It's all fine and dandy that Java got its XML-based build description language. The world out there doesn't all run on Java, though.

It's why I mentioned Gradle as a superior build system: it keeps things declarative, but accommodates several languages from the start. And having seen both sides of the equation, believe me, once you go declarative, you're not going back (hence my disastrous encounter with autotools). It's all an act of balance though, so you'll always be able to find arguments either way.