Meson still won't have user defined functions, and gives a bad excuse:<p>> Meson does not currently support user-defined functions or methods. The addition of user-defined functions would make Meson Turing-complete which would make it harder to reason about and more difficult to integrate with tools like IDEs.<p>No, user-defined functions won't make Meson Turing-complete as long as recursion is not allowed.<p>User defined functions make it easier to encapsulate complicated build logic and reuse it.
2019 was the last time I looked into the CMake vs. Meson debate and while Meson looked 100% saner, cleaner, etc. the network effects of most of the popular C++ libraries using CMake made me end up picking CMake. I'd be curious how the landscape is today but I now have stockholm syndrome with CMake especially using vcpkg.
In my experience, CMake seems to be more capable and easier to work with, both for the package author and for the person trying to build it. Also, more flexible in terms of how projects/packages depend on each other.<p>Now CMake is certainly not great; it has a lot of warts and baggage; and some functionality is _not_ easy to use, like installation (you need a good hour of explanation to make heads from tails with that, and then you're supposed to write 4 or 5 different CMake commands even for the simple use-case of "just install my damn plain-vanilla library"). But I'll choose it over meson any day of the week, and so would my users (i.e. the people who download and build my packages).
I'm using meson, since I started a new job a few months ago and so far I find it to be absolutely delightful, especially compared to cmake.<p>There is almost always only one certain way to do something, which makes it easy to learn, but sometimes frustrating to use, if you're not doing it the "meson way".<p>I also like the .wrap file mechanism to manage dependencies. It's simple, yet powerful enough for our small team and so far we didn't have the need to use a more complex solution.
Every time I have to deal with meson based projects, it needs incredible amount of hacks to build a project if you want to build it in slightly customized way or for bit more different platform. Meson is too smart and often tells you "no you can't do that", which can't be overridden without patching the meson's python code itself.<p>I also find it bit sad, we need python to build something in the first place.
I'm using shell scripts for my small C projects. Works awesome. I dread the time when I'd need to deal with those overcomplicated build systems.
It's really a blessing that this project exists and was so well received and replaced Autotools in many areas already. That said, it has some learning curve for special cases (NB: the fact that it depends on Python may also need some workarounds in bootstrapping environments by e.g. compiling it first to native code or whatever but normally it's not a big deal as Python is around almost everywhere).
Are there any stories/articles on why people chose meson, over say CMake (or others)? I do like meson much more than CMake for sure, sane syntax and all.
I have no knowledge of CMake other than that of a very superficial user. Still I think due to critical mass unless we have something truly ingenuous it is probably better to keep adding missing features to CMake than create other tools from a scratch.
Played with Meson for one hour and bailed out, will stay with makefile/cmake.<p>I especially like cmake that can convert pkg-config from -I header.h to -isystem header.h.
If I had the option between going back in time and killing Hitler, or going back in time and preventing CMake from ever being written, I'd pick the latter every single time[1].<p>Same with Bluetooth, Qt and every other piece of janky garbage that works just well enough to survive, but badly enough that every single person on the planet hates it.<p>[1] This is obviously hyperbole, before anyone gets "HN literal" in the replies.
Something that I learned from listening to Jonathan Blow about his new language Jai is that the implicit assumptions on which traditional C/C++ toolchains are built are horrendously out-of-date.<p>The whole concept of "discovering" which compiler you have, what your linker is, and then using a DSL to generate a script that triggers shell commands is more than a little bonkers if you stand back and look at it objectively.<p>It's common to see SDKs or APIs with 2-10 functions in them that weigh in at over 100 KB due to the overheads of having to deal with toolchains, platforms, and other sideshows that have no real contribution to the business at hand.<p>Jonathan has demonstrated recompiling, linking, and reloading an entire game engine <i>live</i>, which then lets you escape the tarpit of having to add non-compiled DSLs to everything as a workaround for slow compile times. If your compile times are measured in hundreds of milliseconds, scripting isn't needed any more! No more bytecodes, or JIT, or any of that. Just churn the code through a <i>single process</i> that outputs an executable directly and you can sidestep the need for entire industries.<p>This is why tools like CMake or Meson feel to me like they're <i>solving the wrong problem</i>. It's like selling a better horse when automobiles have been demonstrated by Henry Ford.