Since commit 67de5b7b82 (VS: Suppress MSBuild default settings affected
by UseDebugLibraries, 2024-02-13, v3.30.0-rc1~538^2~1) we generate an
empty `Optimization` element for the host compiler when there are no C
or C++ optimization flags enabled. The CUDA Toolkit Visual Studio
integration fails with an error if an empty string is inherited from the
host compiler's `Optimization` element. If no CUDA optimization flags
are specified, write an explicit empty `Optimization` element for the
CUDA compiler too.
Fixes: #26144
Implement the target-wide `CXX_SCAN_FOR_MODULES`/`CMP0155` selection
with the `.vcxproj`-wide `ScanSourceForModuleDependencies` setting.
Set the per-source equivalent only when needed for a per-source
`CXX_SCAN_FOR_MODULES` property.
This approach enables Intellisense for interfaces imported from modules.
It is also more consistent with what a user might expect when
investigating the state of module scanning from the VS property panels.
Fixes: #25806Fixes: #25947
Extend commit 67de5b7b82 (VS: Suppress MSBuild default settings affected
by UseDebugLibraries, 2024-02-13) to cover a `Microsoft.Cl.Common.props`
default from VS 2015 and older.
This indicates to MSBuild which configurations are considered debug
configurations. This is useful for reference both by humans and tools.
Issue: #25327
`Microsoft.Cl.Common.props` changes some default settings based on
`UseDebugLibraries`. CMake models its own controls for these settings,
so if the project does not set them, explicitly suppress them to avoid
letting `UseDebugLibraries` affect them.
405dc7d19c Tests/CXXModules/scan_properties: use `ixx` extension
029ddc3410 cmVisualStudio10TargetGenerator: always specify scanning
6c9614cbf4 Tests/CXXModules: add a test case for VS generation without flags
34f4423851 cmVisualStudio10TargetGenerator: fix typo in flag name
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9104
Offer the capability, through variable `CMAKE_LINKER_TYPE`, as well as
the target property `LINKER_TYPE` to specify which linker must be used.
The implementation of this capability is specified by variables specific
to the language and linker type: `CMAKE_<LANG>_USING_LINKER_<TYPE>`.
Some definitions are provided as part of `CMake`.
For example, to select the `LLVM` linker rather than the standard one,
the type `LLD` should be specified through the variable `CMAKE_LINKER_TYPE`.
And, on `Apple`, `Linux` and some environments on `Windows`, the variable
`CMAKE_<LANG>_USING_LINKER_LLD` has value `-fuse-ld=lld`. And for `Windows`
environments based on `MSVC`, where the linker is used directly, the tool
`lld-link.exe` will be used rather than `link.exe`.
Fixes: #19174, #24254, #24990
Now that scanning support is no longer experimental, the logic for
whether or not to scan C++ 20 sources is now important because all
projects are now exposted to the logic. Make the scanning rules explicit
in the documentation and rework the queries to localize all of the
associated logic.
A policy to handle the ultimate fallback logic will be implemented in a
following commit.
When given objects via `target_link_libraries(consumer PRIVATE producer)` the VisualStudio solution adds the objects
under as `<Object>` entries in the solution.
This works for host side linking but isn't handled by
the cuda msbuild extensions. So to work around this we
manually add the objects as additional link items.
Previously an internal error was raised which ended up causing an
internal exception to be thrown. This is a typo situation that should
fall into an explicit error.
Fixes: #25207
Without `CudaLink` fields, MSBuild tries to perform a device link step
for object libraries with CUDA_SEPARABLE_COMPILATION on them even when
not needed. This commonly was encountered when generating PTX or
OPTIX-IR output.
571b5e1f2c cxxmodules: improve error messages for C++ module setup
8b4d32c18b cmStandardLevelResolver: add query for the effective standard level
17ddc4ac76 cmStandardLevelResolver: compare with static string literals
6f1dae2b01 cmStandardLevelResolver: use `cmStrCat` where possible
0d45d40e13 cmStandardLevelResolver: use character literals where possible
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !8755
The latter call is no longer post-bootstrap only since 596439b1bb
(cmCustomCommandGenerator: Add option to transform depfile, 2020-10-05)
via !5325. Convert callers to just use `cmCryptoHash` directly and
remove the bootstrap guard.
Since commit df58dbb0e9 (VS: Add CMake input files to ZERO_CHECK,
2023-03-19, v3.27.0-rc1~157^2), projects that specify the same file both
as input to `configure_file` and as the `MAIN_DEPENDENCY` of a custom
command fail to configure. Revert the change pending further
investigation. Add a test case demonstrating the problem.
Issue: #24557Fixes: #25149
After b665966933 (cmComputeLinkInformation: track `OBJECT` library
dependencies, 2023-07-22), introduced in !8645 as a fix for #25112,
`OBJECT` libraries were tracked in a separate member to reduce the risk
of further regressions. This commit prepares consumers to handle
`OBJECT` libraries once they start appearing as link items.
`include-what-you-use` diagnostics, in practice, are specific to
the environment's compiler and standard library. Update includes
to satisfy IWYU for our CI job under Debian 12.
