diff options
| author | Matthew Woehlke <matthew.woehlke@kitware.com> | 2026-01-12 15:58:08 (GMT) |
|---|---|---|
| committer | Matthew Woehlke <matthew.woehlke@kitware.com> | 2026-01-12 15:58:08 (GMT) |
| commit | 35d5a4fd6d6bb450375711d17fc630f2af0f7aba (patch) | |
| tree | b63b7a62ce9fa501159b0164ae9ed4d775ae6396 /Tests/RunCMake/FindPython/FindPythonScript.cmake | |
| parent | ad6643019e8c55f7bbc3461281554e0ec19eae66 (diff) | |
| download | CMake-35d5a4fd6d6bb450375711d17fc630f2af0f7aba.zip CMake-35d5a4fd6d6bb450375711d17fc630f2af0f7aba.tar.gz CMake-35d5a4fd6d6bb450375711d17fc630f2af0f7aba.tar.bz2 | |
GenEx: Partially restore pre-CMP0199 behavior of $<CONFIG>
Modify the implementation of policy CMP0199 to only remove the oddball
configuration map matching of `$<CONFIG>` in `NEW` mode, restoring the
old behavior of matching BOTH the consumer's configuration and the
selected configuration of the imported target. It turns out that users
are more dependent on the former than the latter, and while matching
more than one thing is still dodgy, we will likely need to introduce a
new generator expression to match the selected configuration of the
imported target.
Meanwhile, `$<CONFIG>` on targets imported from CPS still only matches
the selected configuration of the imported target, which is the behavior
specified by CPS. However, this can only happen for `$<CONFIG>`
expressions that were generated internally during import.
Update documentation and test cases accordingly.
Fixes: #27487
Fixes: #27495
Diffstat (limited to 'Tests/RunCMake/FindPython/FindPythonScript.cmake')
0 files changed, 0 insertions, 0 deletions