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
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
