I'm actually just learning about Meson for a small project I'm doing. It's... nice in many ways, but you can tell it's still very young. It's trying to avoid

I'm actually just learning about Meson for a small project I'm doing. It's... nice in many ways, but you can tell it's still very young. It's trying to avoid many pitfalls of older projects like CMake by being very strict and opinionated about how it can be used and how you can extend it. This is, I think, a good thing, but that means it also lacks a lot of support that is needed to do certain things. So, it's nice, as long as your build is not too complicated. At least it stops you from building a multiheaded hydra, but at the same time it doesn't cover everything you might need so you can get yourself into a corner if you commit to using it and then discover later that you'll need some functionality it doesn't provide. You know, what I'd _really_ like, the more I think about it, is consistent a way to treat the "build system" simply as a separate project than the "source code". It's just silly how coupled the build system can become with the specific project it's been designed for. More thought is needed towards decoupling build systems from their corresponding target code. The last thing I want as a C/C++ developer is to have to maintain multiple build systems AND make sure everything is correct about what "package files" (pkg-config, CMake targets, etc) they install and where. Lately I find more and more time is spend maintaining build systems than the actual code, and it's very frustrating, and only gets worse as more and more "solutions" become available that require whole new build systems to be designed and integrated. I have several projects that have at least 2 build systems in their repositories, and we have to constantly test them both and make sure they do the same things.