Now, several `INTERFACE_*` properties can be set on `IMPORTED` targets,
not only via `set_property` and `set_target_properties` but also via
`target_compile_definitions`, `target_compile_features`,
`target_compile_options`, `target_include_directories`, `target_sources`
and `target_link_libraries`.
Fixes: #15689
Issue: #17197
393e0fbe cmTimestamp: For symlinks switch to timestamp of resolved path
640709e7 cmSystemTools: Implement GetRealPath on Windows
d41582fc Call GetRealPath through cmSystemTools instead of KWSys directly
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1202
4e7f6738 Defer check for sources within a target until generation.
6e4e7c65 Tests: Exclude bad RunCMake.add_executable case on multi-arch Xcode
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1242
ModifiedTime uses stat on UNIX which does resolve symlinks, however Windows implementation relies on GetFileAttributesExW which does not. Getting real file path before calling ModifiedTime will not change UNIX semantic and will fix Windows behavior.
Fixes: #17206
9ffb3538 VS: Select and save a VS 2017 instance persistently
17edfa41 cmVSSetupHelper: Add option to specify an instance
a19b8113 CheckLanguage: Pass generator instance into check
6b3cd64d ExternalProject: Propagate the generator instance
314613d1 Add infrastructure for generators to select a build tool instance
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1394
The `add_library` and `add_executable` commands can now be called with
no source-files and won't generate a warning or error message, as long
as source-files will be added later via the `target_sources` command.
If during the generation step still no sources are associated with
targets created by such calls a useful error message will be generated
and generation fails.
Targets of type `INTERFACE_LIBRARY`, `UTILITY` or `GLOBAL_TARGET` are
excluded from this check because we do not need sources for these target
types during generation.
Fixes: #16872
Visual Studio 2017 supports multiple instances installed on a single
machine. We use the Visual Studio Installer tool to enumerate instances
and select one. Once we select an instance for a given build tree, save
the result in `CMAKE_GENERATOR_INSTANCE` so we can re-configure the tree
with the same instance on future re-runs of CMake.
Fixes: #17268
Add cache entry `CMAKE_GENERATOR_INSTANCE` to hold the instance location
persistently across re-runs of CMake in a given build tree.
For now we reject the option by default if explicitly set. It will be
implemented on a per-generator basis. Pass the setting into try_compile
project generation. Add a RunCMake.GeneratorInstance test to cover
basic use cases for the option. Verify that `CMAKE_GENERATOR_INSTANCE`
is empty by default, and that it is rejected when the generator does not
support a user setting.
Issue: #17268
d45aa38a Add dev notes for topic 'curl_netrc_options'
60c272b6 ExternalProject: Add support for NETRC and NETRC_FILE suboption
754e39dd Add testcases for file(DOWNLOAD|UPLOAD) netrc options
5d67e902 file(DOWNLOAD|UPLOAD): Add 'NETRC' and 'NETRC_FILE' suboption
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Ruslan Baratov <ruslan_baratov@yahoo.com>
Merge-request: !1376
Rather than injecting `CMakeLists.txt` files into each target's
`SOURCES`, teach the generators to add them during generation using
dedicated code. This avoids mutating the original targets, and avoids
polluting `$<TARGET_PROPERTY:foo,SOURCES>` with generator-specific
content.
This also avoids listing the `CMakeLists.txt` sources in the results of
`CMAKE_DEBUG_TARGET_PROPERTIES==SOURCES` so the `RunCMake.TargetSources`
test no longer needs a separate case for IDEs.
The `TargetMachinePlatform` setting tells CUDA what `--machine {32,64}`
flag to pass to nvcc. While CUDA automatically chooses the proper
default for the target architecture, it does not reflect this in the
user-visible IDE settings. Set it explicitly to fix the user-visible
setting.
Fixes: #17355
The `Microsoft.VisualStudio.Component.VC.Tools.x86.x64` component is
not the only way a VS instance may provide the `cl` compiler tool.
For example, VS 2017 Express Edition does not install that component.
Instead search for the tools directly on disk within an instance.
Suggested-by: Rich Chiodo <rchiodo@microsoft.com>
Fixes: #17349
22beb07f Help: Clarify documentation of NO_SYSTEM_FROM_IMPORTED
2de0e0fd Do not initialize NO_SYSTEM_FROM_IMPORTED on INTERFACE libraries
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1386
The change in commit v3.8.0-rc1~276^2 (Allow NO_SYSTEM_FROM_IMPORTED on
imported INTERFACE libraries, 2016-11-21) was incorrect. The property
is not meant to be set on imported targets at all. It is meant to be
set on their consumers that compile sources. Since INTERFACE libraries
have no sources to compile, the property is not needed on them.
Revert most of that change. Unfortunately we must still tolerate
project code setting NO_SYSTEM_FROM_IMPORTED on INTERFACE libraries
because they were allowed by CMake 3.8 and 3.9.
Issue: #17348
Cygwin-built CMake now converts paths from Cygwin to Windows form
(using cygpath -w) before they're passed to WiX.
The Wix generator on Cygwin requires the libuuid-dev package when
building CMake. However, the DLL it links to is installed by default
as part of Cygwin's core libs, so it does not need to be distributed.
If libuuid-dev isn't available, CMake is simply built without Wix
support on Cygwin.
