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

[ Thread Index | Date Index | More Archives ]

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:"
> "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
> set(CMAKE_DEBUG_POSTFIX <>"-debug-")
> "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
> 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


[1] actually, I wrote CMAKE_BUILD_TYPES on one line, which probably was

Mail converted by MHonArc 2.6.19+