31–40 of 126 posts
Please don't use cmake, the dependency chain it pulls in on a bare machine is massive.
Some CMakefiles have many and gratuitous dependencies but that's the fault of those authors.
IMHO it's the best available CMake book available right now. I especially liked the recommendations at the end of every chapter.
Earlier quoted context omitted.
What's wrong with dependencies?
Every dependency increases the fragility of your program. What if you update the dependency and it breaks your program? What if you have two programs dependent on the same library -- but different versions? This just scratches at the surface of the problem. Sometimes the risk is worth it: you need some complex functionality not worth writing yourself. In that case it's a good thing. But understand that it's a tradeof…
There are times when it makes sense, but those are the special cases, and carry a cost which should be considered.
Please don't use cmake, the dependency chain it pulls in on a bare machine is massive.
I prefer software that uses mature 3rd party libs over NIH driven rewrites. Please also keep in mind that CMake is available for many platforms sone with fading user base like AIX, HPUX, or Solaris. Using a well tested event library like libuv helps to keep those supported.
Earlier quoted context omitted.
What systems does modern CMake not support?
Android NDK supports CMake 3.6 only for example.
See: https://cmake.org/cmake/help/v3.7/manual/cmake-toolchains.7....
The recommended compatibility boilerplate for new projects is tedious. There must be a way to include this knowledge in cmake itself rather than requiring every "properly" configured project to get this right: cmake_minimum_required(VERSION 3.1) if(${CMAKE_VERSION} VERSION_LESS 3.12) cmake_policy(VERSION ${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}) else() cmake_policy(VERSION 3.12) endif() This is all before you ev…
The recommended compatibility boilerplate for new projects is tedious. There must be a way to include this knowledge in cmake itself rather than requiring every "properly" configured project to get this right: cmake_minimum_required(VERSION 3.1) if(${CMAKE_VERSION} VERSION_LESS 3.12) cmake_policy(VERSION ${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}) else() cmake_policy(VERSION 3.12) endif() This is all before you ev…
This syntax is also uber ugly. I can’t understand why C still hasn’t a proper build system that is either using convention over configuration (like Go or Rust) or something like cmake but with a proper syntax (maybe something in pyhon?)
https://cmake.org/pipermail/cmake-developers/2014-September/...
Quote: "The fundamental problem with supporting multiple architectures is that pretty much all of CMake is designed to support one architecture at a time. Modules/*, CMakeCache.txt, etc. are all built around only finding, using, and building one artifact per library (OS X universal binaries work with multiple architectures because they are still only one file). I think even your "toolchain scope" approach would end up being used in practice to wrap the entire CMakeLists.txt file."
And generally it is much easier to use than manually write Makefiles or use Autotools with weird unintuitive syntax. As I remember, they use `dnl` keyword (download?) for comments!