The unity build sources need to be added for all generators. Create
them during `cmGlobalGenerator::Compute` to avoid duplicating the calls
in every generator. We already handle Qt autogen there too.
Issue: #19789
4dc8c153ec Tests: Teach VSWinStorePhone to verify the content of generated xap
481070a78a Tests: Teach VSWinStorePhone to verify the content of generated appx/msix
acdb326610 VS: Do not reference output assemblies of targets with no output
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3778
VS 16.4 introduces an additional check on `CustomBuild` rules that warns
if the outputs of the command are not created. However, CMake supports
marking outputs with the `SYMBOLIC` property to indicate that they will
not actually be generated. That property is used by Makefile and Ninja
generators but has not been needed by the VS generators before. Teach
the VS generator to disable `VerifyInputsAndOutputsExist` in custom
build rules that have a symbolic output.
Fixes: #19737
cmGeneratorExpression::Evaluate is a shortcut when only the evaluated string is
needed or an instance of cmCompiledGeneratorExpression cannot be cached.
Fixes: #19686
Provide a standardized way to handle the C++ "standard" headers
customized to be used with current CMake C++ standard constraints.
Offer under directory `cm` headers which can be used as direct
replacements of the standard ones. For example:
#include <cm/string_view>
can be used safely for CMake development in place of the `<string_view>`
standard header.
Fixes: #19491
Our logic that sets `ReferenceOutputAssembly` in `ProjectReference` has
accumulated a series of conditions for different cases in which the
referenced target has no output. Simplify the condition to check
`GetManagedType` directly for cases with no output.
This will explicitly turn off `ReferenceOutputAssembly` in
`ProjectReference` for utility (i.e. `add_custom_target`) and special
targets (i.e. `ZERO_CHECK`, etc.), and allowing reference of target
dependencies that produce some output.
Fixes: #19665
Previously the CMake didn't compute the required set of libraries
needed to properly device link a static library when
CUDA_RESOLVE_DEVICE_SYMBOLS was enabled.
7786a05c70 Unity build: Add XCode support
1353802af3 Unity build: Add unit tests
8dfeb5d278 Unity build: Add support for Visual Studio generator
7114c141e2 Unity build: Add support for Ninja and Makefile generators
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Stanislav Ershov <digital.stream.of.mind@gmail.com>
Acked-by: Evgeniy Dushistov <dushistov@mail.ru>
Acked-by: Viktor Kirilov <vik.kirilov@gmail.com>
Merge-request: !3611
25f29b9741 cuda: Adapted tests to work with modified cuda toolset
ee86770a3f cuda: Added docs for extended cuda toolset
0ad180d712 cuda: Extend cuda compiler detection to work with custom cuda path
55b0532128 cuda: Extend vs10 target generator to use custom cuda path
df0247a371 cuda: Extend toolset argument to accept path
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3713
It works as expected in Visual Studio.
Visual Studio 2017 will (partially) benefit from the build in
support for unity builds. The custom unity sources are used, because
the build in support doesn't allow batching of certain number of
files. It can do only batching by directory.
Generator expressions in target property VS_CONFIGURATION_TYPE might be used to
set the ConfigurationType to Utility for certain configurations to not build
the target while still linking to the target in other configurations.
Fixes: #19613
This patch is generated by a python script that uses regular expressions to
search for string concatenation patterns of the kind
```
std::string str = <ARG0>;
str += <ARG1>;
str += <ARG2>;
...
```
and replaces them with a single `cmStrCat` call
```
std::string str = cmStrCat(<ARG0>, <ARG1>, <ARG2>, ...);
```
If any `<ARGX>` is itself a concatenated string of the kind
```
a + b + c + ...;
```
then `<ARGX>` is split into multiple arguments for the `cmStrCat` call.
If there's a sequence of literals in the `<ARGX>`, then all literals in the
sequence are concatenated and merged into a single literal argument for
the `cmStrCat` call.
Single character strings are converted to single char arguments for
the `cmStrCat` call.
`std::to_string(...)` wrappings are removed from `cmStrCat` arguments,
because it supports numeric types as well as string types.
`arg.substr(x)` arguments to `cmStrCat` are replaced with
`cm::string_view(arg).substr(x)`
This replaces invocations of
- `cmSystemTools::IsInternallyOn` with `cmIsInternallyOn`
- `cmSystemTools::IsNOTFOUND` with `cmIsNOTFOUND`
- `cmSystemTools::IsOn` with `cmIsOn`
- `cmSystemTools::IsOff` with `cmIsOff`
The mapping for this flag was added by commit 43aa632f57 (VS: Populate
`-Qspectre-` flag table entry for v142, 2019-01-24, v3.14.0-rc1~74^2~7).
However, it did not do anything because the special logic added by
commit bb60ed6e72 (VS: Add flag table entry for -Qspectre, 2018-10-08,
v3.13.0-rc1~4^2) to move the `SpectreMitigation` element from
`ClCompile` to the top level only handled the presence of the setting
and not its value. Extend the special logic to carry the value too.
Fixes: #19535
The `AssemblerListingLocation` setting in VS project files is meant for
intermediate files created during the build much like object files.
When the VS 7 generator was first under development, commit 49aebe6c99
(new arch, 2002-09-04) placed both object files and the ASM list
location in the same directory. Later commit f9aef0e422 (Generator now
creates a separate intermediate files directory for each target,
2005-07-27) moved the object files to a per-target directory but the
ASM list location was not moved with them. Move it now.
Fixes: #19480
In commit 3a53005f7d (Build object library targets in VS, 2012-03-12,
v2.8.8~29^2~13) we updated the condition for unicode but accidentally
left out the SBCS case support for object libraries.
Fixes: #19469
An old workaround for `std::allocator_traits<>::value_type` lints from
IWYU on `std::vector<>` usage breaks IWYU's handling of `<memory>`.
Convert the workaround to use the same approach we already use for a
workaround of `std::__decay_and_strip<>::::__type` lints. Then update
the `<memory>` inclusions to follow the now-correct IWYU lints.
Checks added in commit 81b4d10d8f (CUDA: More exhaustive checks to
determine when to do device linking, 2019-05-09, v3.15.0-rc1~82^2)
assumed that CUDA properties would be set only if CUDA is enabled.
We cannot do a device link step if we do not have the CUDA language
enabled. This was discovered as some projects unconditionally set CUDA
properties such as `CUDA_RESOLVE_DEVICE_SYMBOLS` even when the CUDA
language has not been enabled.
Fixes: #19432
Apply the refactoring from commit 707283981f (VS: Use AddLanguageFlags
to de-duplicate CMAKE_<LANG>_FLAGS* lookup, 2019-04-01,
v3.15.0-rc1~300^2) to the CUDA, ASM_MASM, and ASM_NASM languages too.
In particular, CUDA needs the MSVC runtime library selection logic
in the `AddLanguageFlags` method that is used by other generators.
42e14d90b1 VS: Added support for VS package references for nuget
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Leonid Pospelov <pospelovlm@yandex.ru>
Merge-request: !3389
