4 ms·
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, arch
by 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 agoI 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 agoI 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++).