diff options
| author | Brad King <brad.king@kitware.com> | 2019-01-29 16:54:46 (GMT) |
|---|---|---|
| committer | Brad King <brad.king@kitware.com> | 2019-01-29 17:49:53 (GMT) |
| commit | d9dd68cb60ed09e32cbda8bbd3e31c86a8778e66 (patch) | |
| tree | 8115a6a2ff6650a4011ff6a10d1bb3ee8d7546a9 /Modules/Dart.cmake | |
| parent | 8887ebc69b86606b388272d5c89ce11753bb4804 (diff) | |
| download | CMake-d9dd68cb60ed09e32cbda8bbd3e31c86a8778e66.zip CMake-d9dd68cb60ed09e32cbda8bbd3e31c86a8778e66.tar.gz CMake-d9dd68cb60ed09e32cbda8bbd3e31c86a8778e66.tar.bz2 | |
macOS: Restore compatibility for setting FRAMEWORK after install()
The `FRAMEWORK` target property affects the way the `install()` command
treats the target and so should be set first. Our implementation
assumed that this was always the case and led to an assertion failure.
Prior to CMake 3.12 this was visible only when using an explicit
`LIBRARY ... NAMELINK_ONLY` option, but commit 0212d7c762 (install: add
NAMELINK_COMPONENT argument, 2018-04-18, v3.12.0-rc1~139^2~3) made
it possible with a simple `LIBRARY DESTINATION`.
Fully supporting out-of-order specification will require non-trivial
refactoring to defer install generator creation to generate time.
For now simply restore the old behavior of installing the framework
to the library destination.
Fixes: #18848
Diffstat (limited to 'Modules/Dart.cmake')
0 files changed, 0 insertions, 0 deletions