4 ms·

My experience with working on a project that's converted to Meson is that its main flaw is its philosophical commitment to inflexibility. You do things the Meso

by pm215 6y ago

My experience with working on a project that's converted to Meson is that its main flaw is its philosophical commitment to inflexibility. You do things the Meson way or not at all. Want to have file foo/bar/baz.c compile to foo/bar/baz.o in the build tree? Nope, must be foo_bar_baz.c.o. Want to have source files with a .inc.c extension which aren't compiled like plain .c files? Nope, you need to rename them to .c.inc. Want to write a wrapper function around a Meson builtin like 'dependency' that adds extra functionality to it? Nope, Meson doesn't provide functions in its build scripting language. Want to have a build rule be "run this perl one-liner"? Tough, Meson will mangle it by turning all the backslashes into forward slashes so you need to put it into an external script file. And on and on. And we needed to upstream new functionality into Meson before we could even convert to it in the first place! My view of build tools is that they must provide flexibility and escape hatches, because on a sufficiently complicated project eventually you're going to need it. The Meson designers have a strongly opposed philosophy. If you agree with them on that design philosophy you'll probably be happy using Meson, but if not then you're likely to get frustrated with it every time you do anything non-trivial with it, I think.

simias 6y ago
So I have zero experience with Meson but quite a bit of experience maintaining C++ codebases of varying quality and with all sorts of build systems (qmake, autotools, cmake, simple Makefiles, ...) and honestly I think if you want to make a build system that works reliably, doesn't take 3 months to learn to use correctly and gives you all the features you want you'll have to cut on flexibility. Otherwise you end up with a complicated mess that everybody uses differently and you have to relearn on every single codebase. Rust's cargo is one of the most inflexible build systems I've ever used. It's great. When I open any random Rust crate I know exactly what to expect, where to find what I'm looking for and what I need to tweak to fit my needs. >ant to have file foo/bar/baz.c compile to foo/bar/baz.o in the build tree? Nope, must be foo_bar_baz.c.o. Want to have source files with a .inc.c extension which aren't compiled like plain .c files? Nope, you need to rename them to .c.inc. Great. Sold. Not that I particularly care about these particular stylistic choices, what matters is that I know that any project using Meson will work the same way. I never liked the "mod.rs" convention of Rust, but I definitely think that it would be worse if you could override it on a per-project basis. Again, I have no first hand experience with Meson so maybe it does suck but in my book being opinionated is actually a very good sign and I'll definitely have a look at it if, god forbid, I have to start a new C++ project in the future.
- danhor 6y ago
  Rust's cargo very much has a first mover advantage. Since (almost) all rust projects use cargo, it doesn't have to fit/work with any other styles. I think this position is close to untenable in the C++ ecosystem and for existing codebases therein, since it's too much effort to port large dependencies and thus, it remains very hard to convince people to adopt it. But I'd love seeing something like this, since cargo is pretty much the best thing ever in this space IMHO. The only way I can imagine this working is a very large vendor pushing it hard for their platform. This is effectively just Microsoft, all other platforms either use Java/C#/Swift/JS/... or are much more community driven.

by pm215 6y ago

simias 6y ago

So I have zero experience with Meson but quite a bit of experience maintaining C++ codebases of varying quality and with all sorts of build systems (qmake, autotools, cmake, simple Makefiles, ...) and honestly I think if you want to make a build system that works reliably, doesn't take 3 months to learn to use correctly and gives you all the features you want you'll have to cut on flexibility. Otherwise you end up with a complicated mess that everybody uses differently and you have to relearn on every single codebase. Rust's cargo is one of the most inflexible build systems I've ever used. It's great. When I open any random Rust crate I know exactly what to expect, where to find what I'm looking for and what I need to tweak to fit my needs. >ant to have file foo/bar/baz.c compile to foo/bar/baz.o in the build tree? Nope, must be foo_bar_baz.c.o. Want to have source files with a .inc.c extension which aren't compiled like plain .c files? Nope, you need to rename them to .c.inc. Great. Sold. Not that I particularly care about these particular stylistic choices, what matters is that I know that any project using Meson will work the same way. I never liked the "mod.rs" convention of Rust, but I definitely think that it would be worse if you could override it on a per-project basis. Again, I have no first hand experience with Meson so maybe it does suck but in my book being opinionated is actually a very good sign and I'll definitely have a look at it if, god forbid, I have to start a new C++ project in the future.

danhor 6y ago
Rust's cargo very much has a first mover advantage. Since (almost) all rust projects use cargo, it doesn't have to fit/work with any other styles. I think this position is close to untenable in the C++ ecosystem and for existing codebases therein, since it's too much effort to port large dependencies and thus, it remains very hard to convince people to adopt it. But I'd love seeing something like this, since cargo is pretty much the best thing ever in this space IMHO. The only way I can imagine this working is a very large vendor pushing it hard for their platform. This is effectively just Microsoft, all other platforms either use Java/C#/Swift/JS/... or are much more community driven.