Not necessarily wrong, but you might have to try doing things differently and it might work or not. Meson is certainly less mature than CMake, on the other hand it's much harder to go down a rabbit hole of "Your scientists were so preoccupied with whether they could, they didn't stop to think if they should" and consequent technical debt.
I can see how that can be frustrating. My experience with QEMU's transition to meson is that it was clear from the beginning that Meson would not be able to do everything we needed, but it would let us focus on the few things that are special (e.g. building tests for dozens of targets using dozens of cross compilers) and simplify everything else.
It was not easy: it involved several contributions to meson itself (that everybody now benefits from, for example Postgres), and we do have to live with a couple limitations of the tool, but the outcome was extremely positive:
* 4000 less lines of build system gunk
* A lot fewer requests for help even from experienced developers
* Several new features that required build system hacking could be implemented much more easily
* A transition that did not a require any learning curve for existing developers, because trivial changes to the build system remained trivial
Of course there is still complexity, QEMU still has 11000 lines of build system code. But it was totally worth it.
I'm sure it is better than the previous system, otherwise QEMU would not be migrated to Meson.
But, you're describing a 11,000 line program without the most basic abstraction mechanism known to man - user defined functions.
What are the benefits of not having user defined functions? none, zilch, nada.
The Meson team is grasping at straws trying to claim that having user-defined functions would make it Turing-complete. Without recursion, it won't.
Try to imagine how you would structure those 11,000 lines of code if user-defined functions were available? Would you really write it without extensive use of functions?
It's 11000 lines (for 2.5 million lines of code or so) but it's really a long list of things to do. Functions to look for, libraries to use, configuration symbols to associate with a specific file.
to find a library, but otherwise there's very very little repetition of the kind that can be fixed with user-defined functions.
That's not surprising though. Because the user input is very constrained, I find it more natural to think of the build as "first prepare all these things, then use them to prepare all these other things" and so on, not as a complex program. As a very simple example, instead of abstracting "find flags for the C/C++ compiler" in a function and calling it twice, I prepare an array of languages and iterate on it.
It seems limiting but really it's just different and this kind of data flow mindset makes it very clear what is happening when (e.g. what files or arrays are read and which are written), and it also does not need a lot of abstractions (functions).
What it needs is decent data structures, and Meson's DSL is superior to CMake in that respect. So basically the code you write matches the tools you have.
Now I am not saying that Meson is perfect. But the functions thing is kind of a red herring. My #1 complaint is lack of include files (apart from going down to a subdirectory), not functions. #2 is messy handling of targets that generate files in subdirectories and #3 is a silly handling of some options.
The important thing is that none of these things, and not even functions for that matter, are baked in the language. There is room for fixing them in the future, because they are missing features or bugs rather than fundamental mismatches.
To be honest I believe that Meson should have used Starlark as the language, but it did not exist 10 years ago and anyway there is no Python implementation of it.
I can see how that can be frustrating. My experience with QEMU's transition to meson is that it was clear from the beginning that Meson would not be able to do everything we needed, but it would let us focus on the few things that are special (e.g. building tests for dozens of targets using dozens of cross compilers) and simplify everything else.
It was not easy: it involved several contributions to meson itself (that everybody now benefits from, for example Postgres), and we do have to live with a couple limitations of the tool, but the outcome was extremely positive:
* 4000 less lines of build system gunk
* A lot fewer requests for help even from experienced developers
* Several new features that required build system hacking could be implemented much more easily
* A transition that did not a require any learning curve for existing developers, because trivial changes to the build system remained trivial
Of course there is still complexity, QEMU still has 11000 lines of build system code. But it was totally worth it.