I use Make to automate the initial CMake setup step - though by "Make" I probably mean something more like "glorified shell script", as the Makefile in question

I use Make to automate the initial CMake setup step - though by "Make" I probably mean something more like "glorified shell script", as the Makefile in question consists entirely of phony targets. It detects the OS with the usual bunch of ifs, and by default does one of 3 things: - Windows - generates a VC++ project - OS X - generates an Xcode project - Unix (other) - generates Ninja files for Debug/RelWithDebInfo (Typically there's also the option to generate Ninja files on OS X if you like - good for automated build and/or if you'd just rather use some other editor (which is not unreasonable).) Once it finishes, on Windows you load "build/vs2017/whatever.sln" into VC++; on OS X you load "build/xcode/whatever.xcodeproj" into Xcode; on Unix (other) you change to "build/Debug" or "build/Release" and run "ninja". And off you go. After that, it all just kind of runs itself. The Makefile consists of basically stuff like this: .PHONY:unix unix: rm -Rf build/Debug mkdir -p build/Debug cd build/Debug && cmake -G "Ninja" -DCMAKE_BUILD_TYPE=Debug ../.. rm -Rf build/Release mkdir -p build/Release cd build/Debug && cmake -G "Ninja" -DCMAKE_BUILD_TYPE=RelWithDebInfo ../.. plus some ifs to ensure the right target(s) are available depending on host OS. (I've found it beneficial to regenerate everything entirely from scratch each time in the Makefile - ensures you're always working from a clean slate, with no cached variables sticking around from old runs. The odd package does have an unusually time-consuming configuration process, but I've always ended up managing to bypass these somehow - it's possible a future revision of my "process" will have to actually address this properly.) This process does confuse people that don't read the instructions, as they type "make", some stuff happens, and then nothing. But I've found it to work well enough.