Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everything You Never Wanted to Know About CMake

izzys.casa

Post reply on HN
Print view View original

51–60 of 91 posts

Re: Everything You Never Wanted to Know About CMake

#51

Post by dfgdghdf »

CMake is awful, and the fact that the C++ community seems to be settling around it will be a massive disadvantage in the long run. Why do you think so many WASM examples use Rust? It's because Cargo is a sane build system that makes cross-compilation easy.

Issues with CMake:

- The DSL is not very good. It needs proper functions, for one.

- Non-hermetic builds (also mentioned in this thread)

- No ability to easily query the build DAG

- Headers are not modelled properly (they should be a dictionary of paths -> paths, not a list of include directories)

- Build folders cannot reliably be used between configurations, leading to confusion and cache misses

- Everything is convention driven. It does not model the build graph properly.

- Globs do not work properly (maybe that has changed recently?)

- The cache is not portable across a network, or even between folders on the same machine

The C++ community deserves better!

Others in this thread have mentioned some modern alternatives:

- Buck Build (Facebook, Uber, AirBnB)

- Bazel (Google)

- Pants (Twitter)

- Please (Thought Machine)

It doesn't actually matter which of these succeeds. They all model the builds in such a way that you can easily transpile between them.

Re: Everything You Never Wanted to Know About CMake

#52

Post by shmerl »

dfgdghdf wrote: post #51

CMake is awful, and the fact that the C++ community seems to be settling around it will be a massive disadvantage in the long run. Why do you think so many WASM examples use Rust? It's because Cargo is a sane build system that makes cross-compilation easy. Issues with CMake: - The DSL is not very good. It needs proper functions, for one. - Non-hermetic builds (also mentioned in this thread) - No ability to easily que…

Many C/C++ projects are switching to Meson these days. Mesa for example.

Re: Everything You Never Wanted to Know About CMake

#53

Post by dfgdghdf »

shmerl wrote: post #52
dfgdghdf wrote: post #51

CMake is awful, and the fact that the C++ community seems to be settling around it will be a massive disadvantage in the long run. Why do you think so many WASM examples use Rust? It's because Cargo is a sane build system that makes cross-compilation easy. Issues with CMake: - The DSL is not very good. It needs proper functions, for one. - Non-hermetic builds (also mentioned in this thread) - No ability to easily que…

Many C/C++ projects are switching to Meson these days. Mesa for example.

My experience with Meson is that it is much better designed than CMake but very slow.

Re: Everything You Never Wanted to Know About CMake

#54

Post by shmerl »

dfgdghdf wrote: post #53
shmerl wrote: post #52

Earlier quoted context omitted.

Many C/C++ projects are switching to Meson these days. Mesa for example.

My experience with Meson is that it is much better designed than CMake but very slow.

Meson itself though is just a meta build system, it's used in combination with Ninja that does the actual build. Ninja is quite fast. But they claim at least that they are working on making Meson itself fast too.

Re: Everything You Never Wanted to Know About CMake

#55

Post by dfgdghdf »

whatshisface wrote: post #14
devwastaken wrote: post #8

Earlier quoted context omitted.

Creating your own build tools becomes unmaintainable by anyone else. People do it all the time, and pay the price when they have to change their builds. There is a reason CMake is used by a lot of projects, it's not somehow due to everyones incompetance.

If the build system was a library called from a popular scripting language, it would only take a few minutes of reading the API docs before it builds could be modified. Also, there is a niche for new build systems: one-off projects that "don't matter." If you want to introduce a new build system, your first target market could be throwaway point-a-to-point-b projects and then you could expand outwards from there.

Buck and Bazel work this way. The language is Python (with some optimizations). However, the build is fast because Python is only used to describe the build graph.

Re: Everything You Never Wanted to Know About CMake

#56

Post by dfgdghdf »

shmerl wrote: post #54
dfgdghdf wrote: post #53

Earlier quoted context omitted.

My experience with Meson is that it is much better designed than CMake but very slow.

Meson itself though is just a meta build system, it's used in combination with Ninja that does the actual build. Ninja is quite fast. But they claim at least that they are working on making Meson itself fast too.

This idea of having a "front-end" build system and a "back-end" build system is a bit of a throw-back. It is better to integrate the two for better optimization and configuration management.

Re: Everything You Never Wanted to Know About CMake

#57

Post by j1elo »

dfgdghdf wrote: post #51

CMake is awful, and the fact that the C++ community seems to be settling around it will be a massive disadvantage in the long run. Why do you think so many WASM examples use Rust? It's because Cargo is a sane build system that makes cross-compilation easy. Issues with CMake: - The DSL is not very good. It needs proper functions, for one. - Non-hermetic builds (also mentioned in this thread) - No ability to easily que…

Buck, Bazel, Pants, Please, Meson, Gn, SCons. I haven't even finished reading comments in this HN entry and I'm already lost

Re: Everything You Never Wanted to Know About CMake

#58

Post by archgoon »

dfgdghdf wrote: post #56
shmerl wrote: post #54

Earlier quoted context omitted.

Meson itself though is just a meta build system, it's used in combination with Ninja that does the actual build. Ninja is quite fast. But they claim at least that they are working on making Meson itself fast too.

This idea of having a "front-end" build system and a "back-end" build system is a bit of a throw-back. It is better to integrate the two for better optimization and configuration management.

I don't know if that's true. Don't you gain all the usual advantages of decoupling systems (clarifying responsibilities, documentation, independent growth and optimization, interoperability with other programs, easier testing) if you are forced to define a clear interface between the two?

It certainly seems like specifying a build process and performing a build process are two distinct things.

Re: Everything You Never Wanted to Know About CMake

#59

Post by mdaniel »

sysprogs wrote: post #23

Turns out I'm not alone who spent considerable time fighting with CMake configuration issues. I ended up patching it to support a basic debug server protocol, so you could step through the CMakeLists.txt files in a debugger. In case anyone's interested, here's the CMake fork with debug support [0] and there's a detailed tutorial [1]. [0] https://github.com/sysprogs/cmake [1] https://visualgdb.com/tutorials/cmake/debu…

Have you talked to the CLion team about this, whether to integrate it into the product or make a plugin for it (if such a thing is possible)?

Given how CMake centric CLion is, and how abusively dumb the CMake DSL is, your project sounds like a great thing to teach CLion about.

Re: Everything You Never Wanted to Know About CMake

#60

Post by floatboth »

daenz wrote: post #2

I want to upvote this for solid info, but I want to flag it so fewer people have to know about CMake. It blows my mind that experienced software developers would develop yet another pseudo-language DSL vs creating a portable library (python, java, go, whatever) that has a sensible interface.

No, a good (not turing complete, easy to use, with types) DSL is a good thing. Meson does it right.
Post reply on HN