Thanks Rich! I'm really looking forward to cmake support in vs2017 it should make cross platform development a LOT easier.
I just figured out this thread is actually about two different problems:
1) there's no good way to do 32 vs 64 bit builds with cmake on windows, so the best practice is to commit to an architecture or maintain two build folders if you have to support both architectures. The only annoying thing this that the default arch on windows is Win32 so to generate an x64 project (which is pretty much always the case) you have to flag
-D"Visual Studio 14 2015 Win64" when you generate your project. Not such a big deal if your build system works well and you aren't constantly changing the cmake files...unlike mine
2) This is a new one I JUST figured out. The generated projects have these flags set:
# Static library flags
set( CINDER_STATIC_LIBS_FLAGS_DEBUG "/NODEFAULTLIB:LIBCMT /NODEFAULTLIB:LIBCPMT" )
set( CINDER_STATIC_LIBS_FLAGS_RELEASE "/NODEFAULTLIB:LIBCMT /NODEFAULTLIB:LIBCPMT" )
In debug this seems fine, but in release, it fails to link to the runtime library and all hell breaks loose. Removing the specific ignores on release fixes the problem for me. I also looked at the same sample i'm testing against (_opengl/Cube) and the provided VS proj doesn't ignore them in release, so i think that perhaps this is just a typo?
I'm not super familiar with what that setting is all about so i'm not sure which is the case, but at any rate i'm going to submit an issue and PR about it.
I've tested most of the cmake project generation features for windows and its looking good except for these two things (and a symlink problem i PRed against as well). I'll keep logging things as they come up!