CMP0199

Added in version 4.2.

$<CONFIG:cfgs> only matches the configuration of the consumed target.

Historically, when a $<CONFIG:cfgs> generator expression appeared in the properties of an imported target, it would match (that is, evaluate to 1) if any of the cfgs matched any of the following:

1. The selected configuration of the imported target being consumed.

2. The configuration of the consuming target.

3. Any of the configurations in the MAP_IMPORTED_CONFIG_<CONFIG> of the imported target being consumed (where <CONFIG> is the configuration of the consuming target), whether or not such configurations are valid for the imported target.

This could result in expressions which are intended to be mutually exclusive being concurrently evaluated. This would be especially problematic if the value of a compile definition is intended to be determined by the configuration, as this lack of exclusivity could result in redefinition.

CMake 4.2 and above prefer to consider only the configuration of the imported target being consumed; that is, (1) in the above list.

This policy provides compatibility with projects that rely on the historical behavior. The OLD behavior for this policy is to retain the historic behavior as described above. The NEW behavior is to consider only the configuration of the imported target being consumed.

Note

This policy only applies to generator expressions being evaluated as part of the usage requirements of imported targets which are not imported from Common Package Specification packages.

For non-imported targets, both the historic and ongoing behavior is to consider only the configuration of the consuming target. (The selected configuration of a non-imported target is always the active build configuration, which is necessarily the same as the consuming target's configuration.)

For targets imported from Common Package Specification packages, the NEW behavior is used, regardless of the policy setting.

This policy was introduced in CMake version 4.2. It may be set by cmake_policy() or cmake_minimum_required(). If it is not set, CMake warns, and uses OLD behavior.

Note

The OLD behavior of a policy is deprecated by definition and may be removed in a future version of CMake.

Examples

Consider the following imported libraries:

add_library(test1 INTERFACE IMPORTED)
set_target_properties(test1 PROPERTIES
  IMPORTED_CONFIGURATIONS "DEBUG"
  INTERFACE_COMPILE_DEFINITIONS
    "$<$<CONFIG:debug>:DEBUG>;$<$<CONFIG:release>:RELEASE>"
)

add_library(test2 INTERFACE IMPORTED)
set_target_properties(test2 PROPERTIES
  IMPORTED_CONFIGURATIONS "TEST"
  INTERFACE_COMPILE_DEFINITIONS
    "$<$<CONFIG:debug>:DEBUG>;$<$<CONFIG:example>:EXAMPLE>;$<$<CONFIG:test>:TEST>"
  MAP_IMPORTED_CONFIG_RELEASE "DEBUG;EXAMPLE;TEST"
)

Assume that the consuming project is built in the Release configuration. Under the OLD policy, a consumer of test1 would see both DEBUG and RELEASE defined; $<CONFIG:debug> evaluates to 1 because the selected configuration of test1 is DEBUG, and $<CONFIG:release> evaluates to 1 because the consumer's configuration is Release (keeping in mind that configuration matching is case-insensitive). Likewise, a consumer of test2 would see all of DEBUG, RELEASE and TEST defined; $<CONFIG:debug>, $<CONFIG:example> and $<CONFIG:test> all evaluate to 1 because all of these configurations appear in MAP_IMPORTED_CONFIG_RELEASE.

Under the NEW policy, when test1 is consumed, only $<CONFIG:debug> will evaluate to 1. Similarly, when test2 is consumed, only $<CONFIG:test> will evaluate to 1. Both of these correspond to the configuration of the consumed library that is actually selected by CMake.