Multi-Architecture in CMake and Makefiles - makefile

Question

I'm using CMake to generate solution for Visual Studio and Makefile for Windows. I have already succeeded to make different folder for debug and release types, and i found the two options in my solution.
Now i have 3 questions :
I want to do the same for win32 and x64 ? Is it possible ? EDIT : After some research, it's seem not possible ?)
And the another question, when i generate "NMake Makefiles" i can't retrieve my two types (release and debug) in my makefile ! In which files i can retrieve this ?
EDIT : And how can i set debug or release in CLI with NMake command ?
Here is my CMakeLists.txt :
cmake_minimum_required(VERSION 2.8)
# Configuration of Types
MESSAGE("Generated with config types: ${CMAKE_CONFIGURATION_TYPES}")
SET(CMAKE_CONFIGURATION_TYPES "Debug;Release" CACHE STRING "" FORCE)
#Configuration of zlib.lib
PROJECT(zlib C)
# Path of Release
SET(LIB_RELEASE_PATH "../cmake_x64")
SET( CMAKE_ARCHIVE_OUTPUT_DIRECTORY_RELEASE "${LIB_RELEASE_PATH}/lib/" )
SET( CMAKE_LIBRARY_OUTPUT_DIRECTORY_RELEASE "${LIB_RELEASE_PATH}/lib/" )
SET( CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE "${LIB_RELEASE_PATH}/lib/" )
# Path of Debug
SET(LIB_DEBUG_PATH "../cmake_x64d")
SET( CMAKE_ARCHIVE_OUTPUT_DIRECTORY_DEBUG "${LIB_DEBUG_PATH}/lib/" )
SET( CMAKE_LIBRARY_OUTPUT_DIRECTORY_DEBUG "${LIB_DEBUG_PATH}/lib/" )
SET( CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG "${LIB_DEBUG_PATH}/lib/" )
SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /W3")
ADD_DEFINITIONS("/Gm" -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -D_UNICODE)
# Files of librairy
ADD_LIBRARY(
zlib
STATIC
../.c
and
../.h
)
#Configuration of core.dll
project(core CXX)
# Path of Release
SET(BIN_RELEASE_PATH "../cmake_x64")
SET( CMAKE_ARCHIVE_OUTPUT_DIRECTORY_RELEASE "${BIN_RELEASE_PATH}/bin/" )
SET( CMAKE_LIBRARY_OUTPUT_DIRECTORY_RELEASE "${BIN_RELEASE_PATH}/bin/" )
SET( CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE "${BIN_RELEASE_PATH}/bin/" )
# Path of Debug
SET(BIN_DEBUG_PATH "../cmake_x64d")
SET( CMAKE_ARCHIVE_OUTPUT_DIRECTORY_DEBUG "${BIN_DEBUG_PATH}/bin/" )
SET( CMAKE_LIBRARY_OUTPUT_DIRECTORY_DEBUG "${BIN_DEBUG_PATH}/bin/" )
SET( CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG "${BIN_DEBUG_PATH}/bin/" )
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4")
set_property(GLOBAL PROPERTY LINK_LIBRARY_DEPENDENCIES "yes")
add_definitions(-D_UNICODE -D_USRDLL -DCORE_EXPORTS)
add_definitions("/Gm")
# Files of librairy
add_library(
core
SHARED
../.h
and
../.cpp
)
link_directories("/build/lib/")
target_link_libraries(core zlib)
#END OF FILE
Thanks

Answer 1

I don't know much about nmake or the cmake nmake generator, but if it's anything like the makefile generator then the answer to all three of your questions is "you can't".
For the first question, Visual Studio (to my understanding) doesn't support multiple architectures the way it supports build types; certainly the cmake-generated Visual Studio project files cannot do it.
For the second question, makefiles generated by cmake do not support build types, and I'm assuming nmake has the same limitation. I expect this is just a limitation in the cmake makefile generator; there's no inherent reason in makefiles that multiple build types couldn't be supported.
And similarly for the third question, since you cannot support multiple build types with makefile/nmake output you certainly cannot choose which one to build on the command line.
The answer to all these questions is, you have to re-run cmake with different flags to select different options (architecture and build type).
If what you're concerned about is not having to clean your workspace and reconfigure it from scratch each time and lose your previous work, then you should look into the out-of-source build feature of cmake. Basically, instead of using:
cmake .
you use something like:
mkdir obj-x86
cd obj-x86
cmake ..
mkdir ..\obj-x64
cd ..\obj-x64
cmake ..
You run cmake in a different directory (doesn't have to be a subdirectory) for each different configuration. They can all share the same source tree. Sometimes when you try this for the first time you'll discover issues in your cmake files where they're assuming a particular working directory, etc., and you may need to update them to use variables like CMAKE_SOURCE_DIR rather than relative paths.