3 ms·

> just run cmake . to get yourself a fancy makefile. Well most instructions I've seen start of with "mkdir build && cd build && cmake ../src", which is a bit m

by flukus 8y ago

> just run cmake . to get yourself a fancy makefile. Well most instructions I've seen start of with "mkdir build && cd build && cmake ../src", which is a bit more complicated than just "make" with a default build dir. I'm not sure why they're all like this, I would have though supplying a default build directory is something cmake could handle. My last and only big project with cmake we ended up with a makefile anyway to drive all the things cmake couldn't do, or that we couldn't do with cmake due to inexperience or some combination of the two. So we ended up with make calling cmake calling make, all because it apparently made it easier for IDE users (it didn't but that was definetly our fault).

maccard 8y ago
> I'm not sure why they're all like this, I would have though supplying a default build directory is something cmake could handle. cmake -H. -Bbuild && cmake --build . Will do an out of source build with the default toolchain on windows/mac/linux. Has the added benefit of being parallel, and working with Visual Studio/Ninja/XCode.
tom_ 8y ago
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.

by flukus 8y ago

maccard 8y ago

> I'm not sure why they're all like this, I would have though supplying a default build directory is something cmake could handle. cmake -H. -Bbuild && cmake --build . Will do an out of source build with the default toolchain on windows/mac/linux. Has the added benefit of being parallel, and working with Visual Studio/Ninja/XCode.

tom_ 8y ago

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.