4 ms·

I think this is a demonstration why CMake is bad. Unless it's a general purpose programming language, being Turing complete should always be listed in the "Con

I think this is a demonstration why CMake is bad. Unless it's a general purpose programming language, being Turing complete should always be listed in the "Con" side. It literally means the effort needed to understand its complexity can be unbounded.

kortex 6y ago
Cmake isn't the problem, it's a solution to the complexity of building huge c and/or c++ projects such as VTK such that you can run on many different OSes, arches and platforms, with hundreds of different build options. That is just what you get with legacy build systems. Disclosure: I work at Kitware.
- vlovich123 6y ago
  I think Skylark (the language for Buck/Basel) represents an interesting compromise here that I like better, even though in the past I was a huge Cmake advocate. The majority of rules are declarative and easily understood. Python (or at least a dialect extremely close to Python) is how you extend and write new rules. The two live in very different files (declarative rules are in BUCK/BUILD files, .bzl files contain the imperative definitions of rules, and various other conventions control how you deal with platforms (ie select rules).
- gumby 6y ago
  I think of CMake as a coin with two faces: on one side is a cool engine that manages dependencies and can somehow wrangle Make/xcodebuild/ninja et al. On the other side is a dreadful interface (presumably due to legacy constraints) that you have to gingerly manipulate in the hope that it will cause the proper state changes on the other side so that it can generate the result you want...when I don't actually know what the internals of say Xcodebuild are. It's sort of like using Italian to correspond with someone when you know Latin but not Italian. If the code base really looks like that it might be interesting to implement a different front end. Even XML would be better. On the other hand I couldn't imagine working without it and would be happy if it supported more languages (I only use it with C and C++).
rcxdude 6y ago
It's very hard to avoid turing completeness, and it's normally not particularly valuable to avoid it unless you have some extremely strong requirement for formal reasoning about your code. I've not found that difficulty of understanding correlates well with turing completeness in practice (see regular expressions for an example of a non-turing complete system which are famously difficult to understand). And in the case of a build system specifically, generally if you don't give some generally programmable interface to it then another wrapper layer will appear over it which does. Decisions in build systems are often enough complex enough to warrant a configuration language capable of expressing many different things. (This doesn't necessarily need to be an integral part of the build system: for example rust's package manager/build system, cargo, has a fairly simple non-turing complete configuration file but can run a build.rs program which can through a simple protocol of printing out values adjust many of the decisions cargo makes). In fact, I'd say that CMake suffers most from not embracing that from the start. It's scripting language has clearly grown organically in a messy fashion from a configuration language, instead of being designed from the start with scripting in mind (at which point it may have just been a better idea to use an existing language, like lua, tcl, or python).

kortex 6y ago

Cmake isn't the problem, it's a solution to the complexity of building huge c and/or c++ projects such as VTK such that you can run on many different OSes, arches and platforms, with hundreds of different build options. That is just what you get with legacy build systems. Disclosure: I work at Kitware.

vlovich123 6y ago
I think Skylark (the language for Buck/Basel) represents an interesting compromise here that I like better, even though in the past I was a huge Cmake advocate. The majority of rules are declarative and easily understood. Python (or at least a dialect extremely close to Python) is how you extend and write new rules. The two live in very different files (declarative rules are in BUCK/BUILD files, .bzl files contain the imperative definitions of rules, and various other conventions control how you deal with platforms (ie select rules).
gumby 6y ago
I think of CMake as a coin with two faces: on one side is a cool engine that manages dependencies and can somehow wrangle Make/xcodebuild/ninja et al. On the other side is a dreadful interface (presumably due to legacy constraints) that you have to gingerly manipulate in the hope that it will cause the proper state changes on the other side so that it can generate the result you want...when I don't actually know what the internals of say Xcodebuild are. It's sort of like using Italian to correspond with someone when you know Latin but not Italian. If the code base really looks like that it might be interesting to implement a different front end. Even XML would be better. On the other hand I couldn't imagine working without it and would be happy if it supported more languages (I only use it with C and C++).

rcxdude 6y ago

It's very hard to avoid turing completeness, and it's normally not particularly valuable to avoid it unless you have some extremely strong requirement for formal reasoning about your code. I've not found that difficulty of understanding correlates well with turing completeness in practice (see regular expressions for an example of a non-turing complete system which are famously difficult to understand). And in the case of a build system specifically, generally if you don't give some generally programmable interface to it then another wrapper layer will appear over it which does. Decisions in build systems are often enough complex enough to warrant a configuration language capable of expressing many different things. (This doesn't necessarily need to be an integral part of the build system: for example rust's package manager/build system, cargo, has a fairly simple non-turing complete configuration file but can run a build.rs program which can through a simple protocol of printing out values adjust many of the decisions cargo makes). In fact, I'd say that CMake suffers most from not embracing that from the start. It's scripting language has clearly grown organically in a messy fashion from a configuration language, instead of being designed from the start with scripting in mind (at which point it may have just been a better idea to use an existing language, like lua, tcl, or python).