MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0010202CMakeCMakepublic2010-01-29 05:552010-10-06 14:11
ReporterMarcel Loose 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionCMake 2.8.3Fixed in VersionCMake 2.8.3 
Summary0010202: CMAKE_CONFIGURATION_TYPES and CMAKE_BUILD_TYPE weird behaviour
DescriptionI noticed a behaviour of CMAKE_CONFIGURATION_TYPES and CMAKE_BUILD_TYPE
that is close to wizardry in my opinion when it comes to 'make install'

It seems that 'make install' prefers to use "install configurations"
that are predefined in CMake (i.e. debug, minsizerel, release, etc.)
over user-defined types. If none of the user-defined configuration types
in CMAKE_CONFIGURATION_TYPES matches any of these, "make install"
appears to default to the first item in CMAKE_CONFIGURATION TYPES.

Furthermore, if no matching CMAKE_BUILD_TYPE is specified, 'make
install' seems to use the "most optimized" configuration type of the
predefined types.

Consider the following examples:

$ cmake .. -DCMAKE_CONFIGURATION_TYPES="aap;noot;mies" \
    -DCMAKE_BUILD_TYPE="noot" && make install
...
Install the project...
-- Install configuration: "aap"

cmake .. -DCMAKE_CONFIGURATION_TYPES="aap;noot;mies;debug" \
    -DCMAKE_BUILD_TYPE="noot" && make install
...
Install the project...
-- Install configuration: "debug"

$ cmake .. -DCMAKE_CONFIGURATION_TYPES="aap;noot;release;mies;debug" \
    -DCMAKE_BUILD_TYPE="noot" && make install
...
Install the project...
-- Install configuration: "release"
Steps To Reproduce
Additional InformationI posted a question on the mailing list twice w.r.t. this issue:
  http://www.mail-archive.com/cmake@cmake.org/msg26655.html [^]
  http://www.mail-archive.com/cmake@cmake.org/msg26679.html [^]
but got no repsonse.

TagsNo tags attached.
Relationships
has duplicate 0011950closed Brad King install.cmake file assumes RELEASE install 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2010-01-29 05:55Marcel LooseNew Issue
2010-08-18 11:31Brad KingNote Added: 0021806
2010-08-31 11:44David ColeStatusnew => assigned
2010-08-31 11:44David ColeAssigned To => Brad King
2010-08-31 17:53David ColeTarget Version => CMake 2.8.3
2010-09-08 15:22Brad KingNote Added: 0022141
2010-09-08 15:22Brad KingStatusassigned => closed
2010-09-08 15:22Brad KingResolutionopen => fixed
2010-10-06 14:11David ColeFixed in Version => CMake 2.8.3
2011-03-09 14:19Brad KingRelationship addedhas duplicate 0011950

Notes
(0021806)
Brad King   
2010-08-18 11:31   
CMake has 2 generator types: single-configuration (uses CMAKE_BUILD_TYPE), and multi-configuration (uses CMAKE_CONFIGURATION_TYPES). Makefile generators are single-configuration and should ignore CMAKE_CONFIGURATION_TYPES.

The logic in question is in Source/cmLocalGenerator.cxx in the method cmLocalGenerator::GenerateInstallRules where it computes the "default_config" variable. It was written under the expectation that CMAKE_CONFIGURATION_TYPES would not be defined for Makefile generators. It should be fixed to ask its generator for the set of configuration types, perhaps through a virtual method.

A workaround is to never set CMAKE_CONFIGURATION_TYPES for single-configuration generators.
(0022141)
Brad King   
2010-09-08 15:22   
Fixed:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b06fb166 [^]