CMP0200

Added in version 4.2.

Location and configuration selection for imported targets is more consistent.

The way CMake historically selected the configuration to use for imported targets prioritized selection based on location properties for a candidate configuration and only considered IMPORTED_CONFIGURATIONS as a fallback. This could result in incorrect configuration selection especially for INTERFACE libraries.

CMake 4.2 and above consider IMPORTED_CONFIGURATIONS to be a definitive list of available configurations, regardless of whether a configuration specific location is provided for the library. Additionally, CMake will respect non-configuration-specific locations when a configuration specific location is not specified.

This policy provides compatibility with projects that rely on the historical behavior. The policy setting applies to targets and is recorded at the point an imported target is created. Accordingly, imported packages may override the policy set by the consumer for targets they create. In particular, targets imported from Common Package Specification packages always use the NEW behavior.

The OLD behavior for this policy is to retain the historic behavior. The NEW behavior prioritizes selection based on the advertised list of available configurations. Both behaviors are described in detail below.

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.

Mapped configuration selection

If MAP_IMPORTED_CONFIG_<CONFIG> (where <CONFIG> is the configuration of the consuming target) is set on an imported target, CMake would historically select from that list the first configuration which provides a configuration-specific location. If no such configuration exists, CMake would selects the consuming target's configuration, if the imported target is an INTERFACE library. Otherwise, CMake considers the target as not having a suitable configuration.

For INTERFACE libraries which do not provide a location, this results in CMake always selecting the consuming target's configuration and effectively ignoring MAP_IMPORTED_CONFIG_<CONFIG>. This behavior is not consistent with configuration selection for imported targets which provide a location.

Under the NEW behavior, CMake selects the first configuration from the mapping which appears in IMPORTED_CONFIGURATIONS. If IMPORTED_CONFIGURATIONS is not set, CMake selects the first configuration from the mapping which is "usable". For non-INTERFACE libraries, "usable" means that a location (either configuration-specific or configuration-agnostic) is available. INTERFACE libraries are always considered "usable".

If no match is found, CMake considers the target as not having a suitable configuration.

Non-mapped configuration selection

If MAP_IMPORTED_CONFIG_<CONFIG> is not set, CMake would historically select the first configuration which provides a location out of the following:

• The consuming target's configuration, or

• The empty configuration, or

• The list of configurations in IMPORTED_CONFIGURATIONS.

As an implementation artifact, this results in CMake selecting the last configuration in IMPORTED_CONFIGURATIONS for INTERFACE libraries which do not provide a location. Again, this behavior is not consistent with configuration selection for imported targets which provide a location.

Under the NEW behavior, if IMPORTED_CONFIGURATIONS is set, CMake will select the consuming target's configuration if present therein, otherwise CMake will select the first imported configuration. If IMPORTED_CONFIGURATIONS is not set, CMake will select the consuming target's configuration if it is "usable" (as defined in the previous section); otherwise, CMake considers the target as not having a suitable configuration.

Examples

Consider the following imported library:

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

Under the OLD policy, CMake will select the DEBUG configuration of test (and thus define the symbol DEBUG) for any target linking to test, because CMake does not consider any configuration "valid", and, as an implementation artifact, the last configuration considered is accepted.

Under the NEW policy, the RELEASE configuration will be selected if the consuming project is built in any configuration other than Debug (keeping in mind that configuration matching is case-insensitive). This is because DEBUG will be preferred if the consumer's configuration is also DEBUG, but RELEASE will be preferred otherwise because it appears first in IMPORTED_CONFIGURATIONS, and its appearance therein makes it a "valid" configuration for an INTERFACE library.