WinRT components need to be referenced in a similar way that managed
code libraries are referenced. Validate that the library reference is a
WinRT component and reference it through the project.
Add test coverage for `VS_WINRT_COMPONENT`. While at it, fix the IOT
reference failing on Win10 SDK 17763 which doesn't include it anymore.
Fixes: #18846
a624a3e1b3 Ninja: Use deps=gcc for Intel Compiler on Windows
f4f3b6b9af Ninja: Detect when ninja is new enough to support a multi-line depfile
699cd03212 Ninja: Drop unnecessary deptype customization infrastructure
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2893
91d98542d2 Merge branch 'autogen-qt-version-from-dirprops-release' into autogen-qt-version-from-dirprops-master
062d21c36a Autogen: Read the Qt version from directory properties as well
17ac7c4024 Tests: add cases for providing Qt5Core_VERSION manually
2df6d69014 AutoGen: query Qt5 version from directory properties
b598dfb65e Tests: add cases for providing Qt5Core_VERSION manually
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2883
* The `InTryCompile` member has been unused since commit 62854e9966
(cmState: Move try_compile state from cmake class., 2015-04-11,
v3.3.0-rc1~196^2~9).
* The `ConvertMessageType` and `IsMessageTypeVisible` members have been
unused since commit 421012a330 (cmMessenger: Extract from cmake class,
2016-01-28, v3.7.0-rc1~222^2~1).
* The `InitializeProperties` member has been unused since commit
de722d7d63 (Move property initialization to cmState., 2015-04-06,
v3.3.0-rc1~196^2~1).
Co-Author: Vitaly Stakhovsky <vvs31415@gitlab.org>
Ninja 1.9 supports the depfile format generated by this compiler.
Use `deps = gcc` when the version of Ninja is new enough.
Unfortunately the Intel Compiler for Windows does not properly
escape spaces in paths written to a depfile so if there is a
space in the path we must still fall back to `deps = msvc`.
Fixes: #18855
Ninja 1.9 supports the multi-line depfile format generated by the
Intel Compiler for Windows. Teach the global generator to detect
when the version is new enough to support this.
Do not pass `CMAKE_NINJA_DEPTYPE_<LANG>` in place of `deps = gcc`.
If Ninja ever introduces a new dependency type we will likely need
to update CMake for it anyway.
Using `xcodebuild -enableAddressSanitizer YES ...` causes object files
to be placed in a different directory name. Xcode provides a
placeholder for this that we can use in `OTHER_LDFLAGS` to reference
object files for linking the dependents of object libraries. However,
CMake's features for installing and exporting object libraries depend on
knowing the real path with no placeholders. For these cases, use the
default object directory. Users will then have to choose between
sanitizers and the installation and export features, but both will work
individually.
Fixes: #16289
The `CONFIGURATION_BUILD_DIR` value in the Xcode project file specifies
where to place the library artifact. For object libraries we've used
the `Objects-normal` directory to hide away the `.a` that we otherwise
cannot stop Xcode from producing. The parent of this directory is also
specific to the target and does not vary with Xcode's sanitizer
features, so move the artifact there.
Issue: #16289
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 and warn about the case.
Fixes: #18848
