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
Since commit 33c15ae2b9 (VS: Build custom commands concurrently when
possible, 2023-01-19, v3.26.0-rc1~56^2) we add `BuildInParallel` to
custom commands in `.vcxproj` files. However, this can break existing
projects that implicitly rely on serial execution of custom commands.
For example, custom commands in our FindCUDA module run MSVC (via nvcc)
with a common `vc*.pdb` file, and therefore cannot run in parallel.
Revert use of `BuildInParallel` while leaving most of the infrastructure
for it in place. It can be restored later with an option or policy.
Fixes: #24576
Issue: #18405
The Ninja and Makefile generators honor `target_compile_options` and
friends for ASM_NASM `.asm` sources. Teach the VS generator to
honor them too for consistency.
Issue: #24289
The Ninja and Makefile generators honor `target_compile_options` and
friends for ASM_MARMMASM `.asm` sources. Teach the VS generator to
honor them too for consistency.
Issue: #24289
Since commit 33c15ae2b9 (VS: Build custom commands concurrently when
possible, 2023-01-19) several tests have failed intermittently with the
VS generator. It seems that if the `BuildInParallel` setting is
attached to a generated input:
<CustomBuild Include="generated_input.txt">
<BuildInParallel Condition="...">true</BuildInParallel>
<Command Condition="...">copy geneated_input.txt output.txt</Command>
...
</CustomBuild>
then MSBuild does not wait for the input to be generated before running
the command.
This occurs when using `add_custom_command`'s `MAIN_DEPENDENCY`, so
avoid using `BuildInParallel` in that case.
Issue: #18405
The Ninja and Makefile generators honor `target_compile_options`
and friends for MASM `.asm` sources. Teach the VS generator to
honor them too for consistency.
Fixes: #24289
Extend commit b325484928 (VS: Fix C language standard in target with C++
sources, 2020-09-28, v3.19.0-rc1~74^2) to account for users placing a
`-std:` flag in `CMAKE_C_FLAGS`.
Set the `AppendTargetFrameworkToOutputPath` property to `false` only for
single target SDK-style projects. This prevents outputs from being
overwritten during the build. This revises commit 7671d71299 (VS: Fix
target output paths in SDK-style projects, 2022-09-23, v3.25.0-rc1~82^2).
Fixes: #24094
Issue: #23989
Set the `AppendTargetFrameworkToOutputPath` property to `false` so that
MSBuild does not append anything extra to our standard target output
paths. This fixes the `INSTALL` target, among other things.
Fixes: #23989
Extend the fix from commit a450cc9533 (VS: Set ResolveNugetPackages to
false for ALL_BUILD and ZERO_CHECK, 2021-12-15, v3.23.0-rc1~196^2~1) to
the `PACKAGE` target too.
Revert commit a334f1b906 (VS: Write ZERO_CHECK.proj for VS19 and above,
2021-12-24, v3.24.0-rc1~607^2) and a supporting change from
commit 7219988b00 (VS: Exclude ZERO_CHECK.proj from .sln for
include_external_msproject, 2022-07-15, v3.24.0-rc4~1^2).
The change was made to support `dotnet` tooling in addition to
`msbuild`. However, not having `ZERO_CHECK` in the `.sln` breaks common
interactive workflows. Revert the change for now. Later it can be
re-introduced behind some kind of option that enables `dotnet` support.
Fixes: #23726
Issue: #20227
