good: it’s extremely clean, it’s an actual proper language designed top-down for the problem of describing builds, it contains tons of support for all the common things “unixy” projects need, it’s just a joy to use 99% of the time
frustrating: occasionally the inflexibility hits you, specifically issue #2320 is the one I’m familiar with
easier to learn and handle, and a better specification language than make, automake and cmake
cross-platform (in contrast to e.g. make and automake)
nearly as powerful as cmake and thus a good alternative
What is frustrating about Meson?
requires Python (there are C and C++ versions being developed, but not cross-platform)
while the language is significantly better than cmake’s, it unfortunately has various impractical idiosyncrasies; unfortunately, people who have experience designing languages don’t seem to develop build systems.
build specifications quickly become confusing, which affects the familiarization and maintainability of large projects (though Meson shares this issue with make, automake, cmake and others).
Clean and understandable command-line interface (unlike cmake).
Feature options are a dramatic improvement over booleans (cmake) or --enable-this- –enable-that` (autconf) interfaces.
Designed to accommodate both centralized packages (like Linux distributions) and vendoring, not hostile to either camp (unlike waf).
Fast (mainly thanks to ninja but meson itself is pretty quick too) and more or less reliable.
The general limited/strict philosophy, while annoying at times, does mean that things are pretty consistent and you generally have less trouble understanding whatever meson build definitions you stumble across compared to the alternatives.
Cross-compiling is pretty easy.
Pretty clearly becoming the de facto standard build system for open source stuff at this point, outside of the IDE-centric and especially the MS-centric C++ universe (which more or less considers cmake the solution in this space and consequently tends to hate meson).
Frustrating:
“Batteries included or you’re screwed” philosophy can bite you.
Some pretty fundamental features for libraries are poorly or mis-designed (see below).
Cross compiling may be easy, but the requirement for special files to define things is weird and unnecessary and it should simply use options.
Basically no mechanism for sensible “code” reuse at all, per-project overhead can get pretty high if you aren’t just doing basic things.
Sometimes the opinionated-ness comes through even though what it’s opinionated about is just wrong or at least unnecessarily presumptuous/limiting. Parallel-installable libraries (which need a version suffix in the name) clashing with Windows support that does this all the time there, with no option to turn that off, requiring messy hacks, is a good example of the general way that meson can be frustrating.
At the same time, too lax in some ways. It’s still easy to make a broken project that recompiles things unnecessarily at install time, for example.
Static + shared library support is half-baked. Despite causing a bunch of pain and drama over the extension of static libraries on Windows, you can’t properly build both shared and static libraries on Windows anyway, because the design clashes with exporting symbols (more specifically needing different defines for each). Somehow a build system mainly for C and C++ didn’t really consider exporting symbols which is pretty embarrassing to be honest.
Overall, though, it is by far the least bad build system out there in my opinion. It has its issues, but doesn’t have any deeply-baked “philosophical” issues that I see as particularly problematic, so I feel pretty secure in investing in it.
There’s a bunch of “magic” and especially in build systems I dislike magic. I tend to do weird enough stuff that I end up having to care what’s actually going on. I like make because it’s just a way of stringing together rules for building inputs into outputs. I like ninja because it’s like make but stupider. I don’t mind GN because it generates ninja so you can work out what it’s actually doing, though in $DAYJOB our GN is too complex.
Interesting. So then it’s not actually because of the language, but more because there are too much features to fully comprehend and control. A major difference to MAKE is that you have to specify the details of the process, whereas in Bazel, GN and the like you rather specify the goal, on a higher level. Ninja is essentially a subset of MAKE and not intended to be manually written. It’s interesting that you consider Ninja easier to understand than GN. I came to the conclusion that systems like Bazel or GN are difficult to understand because they are fully dynamic languages where you actually have to run it to understand what happens; that’s why I implemented a statically typed language in BUSY which is amenable to static analysis; so no surprises which you only see at runtime.
It’s probably largely having used bazel with large, existing, complex, slightly buggy bazel rule sets, while having used simpler GN build systems and contributed to their complexity and bugs myself.
Not in any serious way. For me anyway, mainly releasing C and C++ source code intended to be built by a diverse range of people on an impossibly diverse set of platforms, any weird/esoteric/unknown build system is a huge liability in many ways.
That said, specifically to Bazel: I don’t do Java, and investing in anything internal from Google is a fool’s errand. gyp, then gn, then bazel… probably even more I haven’t heard of. I know internal engineer wanking when I see it. To be fair, they seem to be treating bazel a bit more seriously and it’s not egregiously half-baked like its predecessors, but still.
I know nothing of Pants other than that it’s clearly not for me.
Subprojects: You don’t need to provide your own package manager or choose between that, pkg-config or CMake modules, because you can declare the right pointers and let Meson give your users the choice.
Not a stringly typed macro style language: Instead of dynamically named variables that come from nowhere when you search for them, you can follow them through objects and assignments. Also, does not simply make empty strings out of undefined variables.
Inflexible (compared to CMake):
For better or for worse, the language itself is not extensible like CMake. Of course, it has custom targets, so it’s not that: There is not a thing you can’t do at build time. But the language itself is not turing complete. You have to add your missing feature to Meson itself. Maybe great in the long run if you can upstream it; not so much if it’s just for internal use. It also means that Meson accumulates features fast – good luck rewriting it in Rust.
What is good about Meson?
What is frustrating about Meson?
good: it’s extremely clean, it’s an actual proper language designed top-down for the problem of describing builds, it contains tons of support for all the common things “unixy” projects need, it’s just a joy to use 99% of the time
frustrating: occasionally the inflexibility hits you, specifically issue #2320 is the one I’m familiar with
Adding to the others mentioned so far, good:
--enable-this-–enable-that` (autconf) interfaces.Frustrating:
Overall, though, it is by far the least bad build system out there in my opinion. It has its issues, but doesn’t have any deeply-baked “philosophical” issues that I see as particularly problematic, so I feel pretty secure in investing in it.
Have you tried Basel/Pants/etc?
I find huge cognitive load trying to use Bazel - and I’ve worked at Google for a decade.
Because of the specification language or other aspects? How about GN? Have you an example of a build system with little “cognitive load”?
There’s a bunch of “magic” and especially in build systems I dislike magic. I tend to do weird enough stuff that I end up having to care what’s actually going on. I like make because it’s just a way of stringing together rules for building inputs into outputs. I like ninja because it’s like make but stupider. I don’t mind GN because it generates ninja so you can work out what it’s actually doing, though in $DAYJOB our GN is too complex.
Interesting. So then it’s not actually because of the language, but more because there are too much features to fully comprehend and control. A major difference to MAKE is that you have to specify the details of the process, whereas in Bazel, GN and the like you rather specify the goal, on a higher level. Ninja is essentially a subset of MAKE and not intended to be manually written. It’s interesting that you consider Ninja easier to understand than GN. I came to the conclusion that systems like Bazel or GN are difficult to understand because they are fully dynamic languages where you actually have to run it to understand what happens; that’s why I implemented a statically typed language in BUSY which is amenable to static analysis; so no surprises which you only see at runtime.
It’s probably largely having used bazel with large, existing, complex, slightly buggy bazel rule sets, while having used simpler GN build systems and contributed to their complexity and bugs myself.
Not in any serious way. For me anyway, mainly releasing C and C++ source code intended to be built by a diverse range of people on an impossibly diverse set of platforms, any weird/esoteric/unknown build system is a huge liability in many ways.
That said, specifically to Bazel: I don’t do Java, and investing in anything internal from Google is a fool’s errand.
gyp, thengn, thenbazel… probably even more I haven’t heard of. I know internal engineer wanking when I see it. To be fair, they seem to be treating bazel a bit more seriously and it’s not egregiously half-baked like its predecessors, but still.I know nothing of Pants other than that it’s clearly not for me.
Good (compared to CMake):
Inflexible (compared to CMake):
For better or for worse, the language itself is not extensible like CMake. Of course, it has custom targets, so it’s not that: There is not a thing you can’t do at build time. But the language itself is not turing complete. You have to add your missing feature to Meson itself. Maybe great in the long run if you can upstream it; not so much if it’s just for internal use. It also means that Meson accumulates features fast – good luck rewriting it in Rust.