mirror of
https://gitlab.kitware.com/cmake/cmake.git
synced 2026-01-29 20:34:20 +00:00
a96b426206
While evaluating best practices related to CPS configuration use, a question was raised as to what configuration mapping CMake uses to choose the configuration of a target linked by another imported target for which a non-standard configuration was chosen; namely, does CMake use the `MAP_IMPORTED_CONFIG_<CONFIG>` for the configuration associated with the most ancestral target / the project's build type, or for the selected configuration of the direct consumer of the target? It turns out the answer is "the former", and that this is actually the more user-beneficial choice, as it allows users to craft configuration maps that easily allow multi-axis configuration selection on correctly crafter hierarchies, which are something CPS has "recommended" almost since its inception (but CMake cannot presently generate). This has three effects. First, it means that CPS suggesting such hierarchies as a way to implement multiple configuration axes is not actually as insane as it would be otherwise. Second, it means that consumers can specify mappings for transitively included targets without needing to know or care about what configurations of the intervening targets exist. Third, it means that the current behavior is desirable, and having something which verifies that behavior is useful. Thus, this adds a test to do exactly that. There are no actual behavior changes here; the test only verifies the already existing behavior.
23 lines
412 B
C++
23 lines
412 B
C++
#define _STR(x) #x
|
|
#define STR(x) _STR(x)
|
|
|
|
enum vocalization
|
|
{
|
|
meow, // tame cat
|
|
roar, // wild cat
|
|
whine, // tame dog
|
|
growl // wild dog
|
|
};
|
|
|
|
#if __cplusplus >= 201103L || (defined(_MSVC_LANG) && _MSVC_LANG >= 201103L)
|
|
static_assert(NOISE == EXPECTED,
|
|
"expected " STR(EXPECTED) ", got " STR(NOISE));
|
|
#else
|
|
typedef int test[(NOISE == EXPECTED) ? 1 : -1];
|
|
#endif
|
|
|
|
int main()
|
|
{
|
|
return 0;
|
|
}
|