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.
b9c99830c5 VS: Fix C++ modules in source files with the same name
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !8596
When multiple source files in a single target have the same name, we
already set `ObjectFileName` explicitly to avoid a `.obj` collision. For
C++ module sources, set `Module{Output,Dependencies}File` to avoid
`.ifc` and `.module.json` collisions.
Fixes: #25038
VS 17.6 now implements `ScanSourceforModuleDependencies` using the same
`cl /scanDependencies` scanner that our Ninja generator uses. It can
distinguish module internal partitions from module interface units based
on their content. Switch from `CompileAsCppModule` to `CompileAsCpp`
for `CXX_MODULES` sources so that MSBuild can scan and classify them.
Add all cmake input files to the `ZERO_CHECK` project. Place files
under `CMAKE_SOURCE_DIR` in a folder structure matching the directory
structure. This way they are easier to find, and Visual Studio does not
close them when reloading the project.
Fixes: #24557
In commit 33c15ae2b9 (VS: Build custom commands concurrently when
possible, 2023-01-19, v3.26.0-rc1~56^2) we added `BuildInParallel` to
custom commands in `.vcxproj` files, but that had to be reverted by
commit abb1c12162 (VS: Revert "Build custom commands concurrently when
possible", 2023-03-07, v3.26.0-rc6~3^2) because some projects may have
custom commands that accidentally rely on serial execution in MSBuild.
Add a policy to use `BuildInParallel` for custom commands in projects
that have been updated to set the policy to `NEW`.
Fixes: #18405
