This is the 'old' way of doing CMake -- the 'modern' transitive variants like target_include_directories and target_link_libraries have many advantages relative to the older usage.
I found CMake scripts really hard to grok but I think that was because I was trying to learn by reading ones other people had made.
I found it helpful to build a simple app composed of a few C++ files, headers and library dependencies and then write the bare minimum CMake script to build it. After that, I just keep iterating, adding CMake features, turning on or off C++ features, making it work on other platforms, compilers, bit-widths etc.
Now, I can't imagine starting a C++ project without using it.
Note that the variables in the "Detecting an operating system" section are for detecting the target operating system, not the host (what CMake is running on). If you use a toolchain file to cross-compile from Linux to Windows, for example, WIN32 will be defined instead of UNIX.
The target property overrides the global setting, so you can set CMAKE_CXX_STANDARD as the default and then set the target property if you really need a different standard for some reason. And if you have a whole sub-project that needs a specific version, you can set CMAKE_CXX_STANDARD before calling add_subdirectory to have it apply to only the targets in that directory.
Little known cmake feature: instead of running "make" after running cmake, do a 'cmake --build .':
$ mkdir build
$ cd build
$ cmake ../
$ cmake --build .
This has the advantage that it works for every generator on every platform, since cmake knows how to invoke the right command line build tool for the generator (make, ninja, msbuild, xcodebuild etc).
"Instead of fiddling around with autotools madness..." --- in my years of packaging software I have found autotools to be the least maddening of all build tools. Autotools is weird for developers, but it's remarkably consistent and easy to use for users (such as packagers).
11 comments
[ 4.1 ms ] story [ 31.9 ms ] threadThis is the 'old' way of doing CMake -- the 'modern' transitive variants like target_include_directories and target_link_libraries have many advantages relative to the older usage.
I found it helpful to build a simple app composed of a few C++ files, headers and library dependencies and then write the bare minimum CMake script to build it. After that, I just keep iterating, adding CMake features, turning on or off C++ features, making it work on other platforms, compilers, bit-widths etc.
Now, I can't imagine starting a C++ project without using it.
$ mkdir build
$ cd build
$ cmake ../
$ cmake --build .
This has the advantage that it works for every generator on every platform, since cmake knows how to invoke the right command line build tool for the generator (make, ninja, msbuild, xcodebuild etc).