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

[Peter Wang <novalazy@xxxxxxxxxx>]

On 2010-07-12, John Murphy <wonsungi@xxxxxxxxxx> wrote:
> 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"

That should be r11386.  Milan might remember something.

> 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.

Sounds reasonable.

> Additionally, this commit
> also bundles remarks/diffs for "Fixed static linking of examples." Are these
> changes related?

Doesn't look it.

> 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 <http://www.cmake.org/Wiki/CMake_2.8.1_Docs>"-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).

We'd need to ensure it generates the right names on other platforms, but
it should be fine.

> 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
> <http://www.cmake.org/Wiki/CMake_Useful_Variables>(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?

Certainly I was unaware that CMake supports multiple configurations at
once[1], so there might be assumptions lurking.  Based on a search for
CMAKE_BUILD_TYPE, I can only see one problem (other than naming), where
we conditionally set D3D_DEBUG_INFO.  But CMake already supports
defining different symbols for different build types so it is easily
fixed.

Peter

[1] actually, I wrote CMAKE_BUILD_TYPES on one line, which probably was
intended to be CMAKE_CONFIGURATION_TYPES.