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.
b32b717b cmInstallCommandArguments: do not access static members through `this`
7eaa964e cmProcessTools: fix minor issue introduced by 595feb385a7eaba cmGeneratorTarget: remove dead code
3345e2a2 cmcmd: let operator<< for NumberFormatter reset the stream's format flags
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1349
Brad King