Hacker News Reader

Comment by radarsat1 | Hacker News Reader

If only CMake weren't just as awful. It seems to have become an industry standard yet I can't begin to tell you how much time I've wasted wrestling with it lately. In an ideal world all projects would use CMake "correctly" but it's just not the case; problems are really hard to debug, no one really seems to know the current "right way" to do things, and the "right way" keeps changing anyway.

Coupled with an awful language, I just can't say that CMake is better, or much better, than autotools. But at least it handles Visual Studio and ninja. So yeah, we use it for the support it provides which is second-to-none, but it's a mostly terrible user experience, frankly.

View on HN

The only reason CMake is considered better than automake is because automake is so unimaginably dreadful. CMake is a lot worse than pretty much any competent piece of software.

Yet CMake is much better and comes with support for installers (Deb/rpm/MSI/DMG), which is a killer feature.

And now it's even better to couple it with Conan for dependency management

Ignoring the qt part entirely, I think qmake is the best of the bunch.

Qt is moving to CMake too. And the latest versions of CMake are as good, or better, than qmake. Add to that vcpkg and you will have a fantastic solution for managing dependencies.

Maybe CMake is not the best but is good enough and the new standard in the C++ world.

It’s really not good enough, it’s ok to admit it. Nobody likes CMake, it just somehow won the makefile generator wars. Having to a learn shitty, esoteric language to compile my code Is not something that makes me more productive.

> Having to a learn shitty, esoteric language to compile my code Is not something that makes me more productive.

You say that but frankly between CMake code and Ant or msbuild ...

Qmake. It’s simple, it’s cross-platform, it gets out of my way.

it's also going the way of the dodo as Qt 6 is migrating to CMake :p

5 will get forked because of the way 6 is being licensed.

6 will be licensed like 5 : https://www.embeddeduse.com/2019/12/21/safe-guarding-the-lgp...

I agree. qmake was much, much better to work with than cmake. I tend to believe the reason cmake won is because qmake was so associated with Qt. The best tech does not always win.

Android also settled with cmake, while keeping the original ndk-build makefile based one, after doing a couple of failed attempts to switch to something else.

After 10 years they are finally introducing AAR support for NDK projects, which is also built on top of cmake.

qmake is has very poor handling of dependencies between generate header files, like those used with protobuf.

https://github.com/jmesmon/qmake-protobuf-example

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

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.

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

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.

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.)

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.

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.

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.

Reply on news.ycombinator.com