We have recently stumbled across this problem, tracked in Mantis at: http://www.cmake.org/Bug/view.php?id=12532
On 19 Oct 2011, at 11:18, Daniel Dekkers wrote: > I still have issues with the CMake feature to define different settings for > different configurations in Xcode (4.0.2). > Related to... > > http://www.cmake.org/Bug/view.php?id=11667 > http://www.cmake.org/Bug/view.php?id=8179 The history is that the fix for 11667 added support for Xcode's own attribute condition system, which included 'variant=(Debug|Release)'. However, that doesn't work in recent versions of Xcode and CMake because where the attributes should get put has moved to within the configuration definition. [variant=<variant>] is still supported by Xcode but it just doesn't work correctly. > I've tried lots of different interpretations of the syntax (which is > undocumented apart from the bug tracker?) but nothing seems to work, if I try > this... > > SET_TARGET_PROPERTIES( ${RT_APP_NAME} PROPERTIES > XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY[variant=Debug] > ${RT_CODE_SIGN_IDENTITY_DEVELOPMENT} ) > SET_TARGET_PROPERTIES( ${RT_APP_NAME} PROPERTIES > XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY[variant=Release] > ${RT_CODE_SIGN_IDENTITY_DISTRIBUTION} ) > > or... > > SET_TARGET_PROPERTIES( ${RT_APP_NAME} PROPERTIES > XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY[variant=Debug][sdk=*] > ${RT_CODE_SIGN_IDENTITY_DEVELOPMENT} ) > SET_TARGET_PROPERTIES( ${RT_APP_NAME} PROPERTIES > XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY[variant=Release][sdk=*] > ${RT_CODE_SIGN_IDENTITY_DISTRIBUTION} ) > > ... it always results in both settings being added to both configurations > (under the key "Any sdk" that is added twice per configuration). There's a patch at: http://kervala.net/download/cmake-xcode-attributes-variant.patch which is linked to from bug 12532. It "fixes" the [variant=Debug] syntax by interpreting it directly at the Xcode generator stage. That would effectively fix the feature as added by the fix for bug 11667. I don't find this patch very satisfying because it effectively introduces Xcode syntax into the CMake language by the back door. Bug 12532 has another suggestion which is to allow _<CONFIG> variants, as in XCODE_ATTRIBUTE_<ATTRIBUTE>_<CONFIG>. I don't think that's a great way to do it either, as it creates a syntactic ambiguity between eg. the 'DEBUG' variant of ATTRIBUTE, and a theoretical Xcode attribute ending in '_DEBUG'. As far as I know there are no current Xcode attributes ending in _DEBUG, _RELEASE, _RELWITHDEBINFO, or _MINSIZEREL, but it could easily cause a problem for user-defined configurations. My suggestion is that the desired behaviour could be possible via a new XCODE_ATTRIBUTES target property, itself having _CONFIG variants, which is set to a CMake list of attribute/value pairs. Eg. set_target_properties(MyTarget PROPERTIES XCODE_ATTRIBUTES_DEBUG "CODE_SIGN_IDENTITY=${RT_CODE_SIGN_IDENTITY_DEVELOPMENT} ;DEBUG_INFORMATION_FORMAT=DWARF") The new XCODE_ATTRIBUTES and XCODE_ATTRIBUTES_<CONFIG> would be generated in addition to the current XCODE_ATTRIBUTE_<ATTRIBUTE> attributes, so existing working code wouldn't be broken, although it would probably be sensible to deprecate the old version and have users standardise on the new way. Work would be needed to correctly parse attributes that use Xcode conditions, such as: set_target_properties(MyTarget PROPERTIES XCODE_ATTRIBUTES "CODE_SIGN_IDENTITY[sdk=*]=${RT_CODE_SIGN_IDENTITY_DISTRIBUTION}") Sound sensible/doable? Matthew -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
