4 ms·

> This isn't the kind of a job that can be solved by a simple, beautiful 50 line file. As a big CMake fan, I don't think CMake's success has anything to do wit

> This isn't the kind of a job that can be solved by a simple, beautiful 50 line file. As a big CMake fan, I don't think CMake's success has anything to do with their super ugly custom language. What CMake does could be a lot more ergonomic, especially from a typical user's standpoint.

SXX 9y ago
Typical user doesn't need project generation for 10 different IDEs, OS and packages formats with multiple backends and built-in test support. If you drop half of features then I guess it's could actually become a lot more ergonomic, but in this case there likely tools with better support. Real pain is that a lot of CMake features are badly documented and most of available information is outdated, but this is usual problem at least for open source C++ projects so it's doesn't cause a lot of frustration and no one try to fix it.
- alacombe 9y ago
  We do, while we're not doing anything crazy, ie. support for 3 major OS (Windows, Linux, macOS), 3 major build-system (VC, GNU make, Xcode), 3 different compiler (VC, gcc, and clang), 7 different product packaging (RPM, DEB, TGZ, Windows, Mac, Alpine, Android), as well all kind of debug / release custom setup.
- lomnakkus 9y ago
  Exactly. Another point I'd like to add here: CMake basically takes to you what autoconf/automake can do (+ 5/10 years of improvement on UX/UI), but it: a) doesn't use absurd amounts of slow shell code trying to detect features that no (non-EOL) OS has been missing for the last 20 years. b) is actually reasonably readable. (Ok, m4 is sort of readable, but it a bit weird in places.) c) is actually better documented (IME) than autoconf/automake. What people usually do for autoconf/automake is just copy/paste another project/snippet. .. hence leading to the 20+ years problem. (I'll definitely agree that the docs aren't great, but that's at least a problem that can practically be fixed unlike the copy/paste problem of autoconf/-make.)

SXX 9y ago

Typical user doesn't need project generation for 10 different IDEs, OS and packages formats with multiple backends and built-in test support. If you drop half of features then I guess it's could actually become a lot more ergonomic, but in this case there likely tools with better support. Real pain is that a lot of CMake features are badly documented and most of available information is outdated, but this is usual problem at least for open source C++ projects so it's doesn't cause a lot of frustration and no one try to fix it.

alacombe 9y ago
We do, while we're not doing anything crazy, ie. support for 3 major OS (Windows, Linux, macOS), 3 major build-system (VC, GNU make, Xcode), 3 different compiler (VC, gcc, and clang), 7 different product packaging (RPM, DEB, TGZ, Windows, Mac, Alpine, Android), as well all kind of debug / release custom setup.
lomnakkus 9y ago
Exactly. Another point I'd like to add here: CMake basically takes to you what autoconf/automake can do (+ 5/10 years of improvement on UX/UI), but it: a) doesn't use absurd amounts of slow shell code trying to detect features that no (non-EOL) OS has been missing for the last 20 years. b) is actually reasonably readable. (Ok, m4 is sort of readable, but it a bit weird in places.) c) is actually better documented (IME) than autoconf/automake. What people usually do for autoconf/automake is just copy/paste another project/snippet. .. hence leading to the 20+ years problem. (I'll definitely agree that the docs aren't great, but that's at least a problem that can practically be fixed unlike the copy/paste problem of autoconf/-make.)