4 ms·

I thought the hip thing these days is to use Meson for C/C++ builds?

ComputerGuru 6y ago
Meson is excellent and would have eaten CMake out of house and home if it weren’t for the stupidity of it targeting C/C++ but being written in Python. A lot of C/C++ developers cringe at the thought of requiring Python as a build dependency.
- boris 6y ago
  You may want to check build2[1] then. As a bonus you also get a Cargo-like package/project manager (but with a real build system underneath). Full disclosure: I am involved with the project. [1] https://build2.org https://build2.org
- pjmlp 6y ago
  Gradle, implemented in a mix of Java and Groovy Maven, Ant, implemented in Java Sbt, implemented in Scala Leinigen, implemented in Clojure MSBuild, implemented in a mix of C++ and C# Gems, implemented in Ruby eggs, implemented in Python cargo, implemented in Rust Why should it be any different for C and C++? So vcpkg it is.
  - ComputerGuru 6y ago
    Complete aside: I often find myself agreeing with contrarian or somewhat contentious dev-related posts here and on GitHub (I’m mqudsi there), look to the name of the author, and see yours. (I’m not sure why I decided to share this right now. Sorry.)
- radarsat1 6y ago
  For me at least, using Python is the least of my concerns, in fact I like Python so having the build system in a familiar language instead of some esoteric DSL would be wonderful. Unfortunately SCons was too slow and had its own problems, but it wasn't a bad idea imho. That said one thing I like about autotools is how it generates a build system that doesn't depend on more than shell script and make, and can be packaged that way. It's annoying that CMake produces a build system that requires CMake to be present to build.
  - ComputerGuru 6y ago
    I actually philosophically minded SCons less than meson as the former never pretended to be a build system that just happened to require Python as a minor detail to gloss over or wishfully pretend didn’t matter; it put it out there front and center.
radarsat1 6y ago
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.

Meson is excellent and would have eaten CMake out of house and home if it weren’t for the stupidity of it targeting C/C++ but being written in Python. A lot of C/C++ developers cringe at the thought of requiring Python as a build dependency.

boris 6y ago
You may want to check build2[1] then. As a bonus you also get a Cargo-like package/project manager (but with a real build system underneath). Full disclosure: I am involved with the project. [1] https://build2.org https://build2.org
pjmlp 6y ago
Gradle, implemented in a mix of Java and Groovy Maven, Ant, implemented in Java Sbt, implemented in Scala Leinigen, implemented in Clojure MSBuild, implemented in a mix of C++ and C# Gems, implemented in Ruby eggs, implemented in Python cargo, implemented in Rust Why should it be any different for C and C++? So vcpkg it is.
- ComputerGuru 6y ago
  Complete aside: I often find myself agreeing with contrarian or somewhat contentious dev-related posts here and on GitHub (I’m mqudsi there), look to the name of the author, and see yours. (I’m not sure why I decided to share this right now. Sorry.)
radarsat1 6y ago
For me at least, using Python is the least of my concerns, in fact I like Python so having the build system in a familiar language instead of some esoteric DSL would be wonderful. Unfortunately SCons was too slow and had its own problems, but it wasn't a bad idea imho. That said one thing I like about autotools is how it generates a build system that doesn't depend on more than shell script and make, and can be packaged that way. It's annoying that CMake produces a build system that requires CMake to be present to build.
- ComputerGuru 6y ago
  I actually philosophically minded SCons less than meson as the former never pretended to be a build system that just happened to require Python as a minor detail to gloss over or wishfully pretend didn’t matter; it put it out there front and center.

radarsat1 6y ago

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.