[AD] CMake: enabling multiple configurations within a single MSVC solution file

[John Murphy <wonsungi@xxxxxxxxxx>]

I'm looking for the motivation behind commit r11836, added to "restrict MSVC's configuration types to the selected build type:"

set(CMAKE_CONFIGURATION_TYPES "${CMAKE_BUILD_TYPE}" CACHE INTERNAL "internal"

My best guess is: to ensure the Allegro libraries' build types match their filenames. (i.e. prevent the release DLL from having "debug" in its name and make sure the debug DLL has "debug" in its name.) If this line is commented out, it is possible for such a mismatch to result. Additionally, this commit also bundles remarks/diffs for "Fixed static linking of examples." Are these changes related?

It would be nice to have multiple configurations from the same MSVC solution file. The RelWithDebInfo build is much faster, but I switch to the more precise Debug build to pinpoint problems. Also multiple configurations can be built in batch.

If the only issue is proper naming of library files, I propose we use CMake's ability to add a custom "postfix" based on the CMAKE_CONFIGURATION_TYPE:

set(CMAKE_DEBUG_POSTFIX "-debug-")

# set(CMAKE_CONFIGURATION_TYPES "${CMAKE_BUILD_TYPE}" CACHE INTERNAL "internal")

The value of CMAKE_DEBUG_POSTFIX is inserted between the targetname and soversion suffix (allegro-debug-4.9.dll).

I'm not sure what the Allegro naming scheme for all the different BUILD_TYPES is, but there is a CMAKE_*_POSTFIX variable for each possible configuration type (RELWITHDEBINFO, DEBUG, RELEASE, etc...) I have tried this successfully with Visual Studio Express 2010. I haven't really worked with the statically linked version of Allegro, so I am not sure if static linking will cause any problems. I don't foresee any problems, though.

So are there any other reasons for restricting MSVC's configuration types to the selected build type?

John