Starting with VS 17.10 the v143 toolset reserves versions `14.30`
through `14.49`. This is the first time that the first three digits of
the version do not match the toolset name. Extend the special case from
commit d256581bb0 (VS: Fix '-T version=14.40' under VS 17.10 preview 1,
2024-02-19, v3.29.0-rc2~10^2) to cover the entire reserved version range.
VS 17.10 preview 1 comes with toolset `v143` version `14.40`. This is
the first time that the first three digits of the version do not match
the toolset name. Add a special case to map version `14.40` back to
toolset `v143`.
In commit 5f13168419 (VS: Add option to select the version of the
toolset used by VS 2017, 2018-05-19, v3.12.0-rc1~38^2) we added logic to
verify that the toolset version, such as `14.35`, matches the toolset
name, such as `v143`. Clarify the logic to not construct a temporary
nonsensical toolset name like `v1435`. Also verify the format of the
toolset version more strictly, e.g., to reject `14.350` earlier.
Previously the latter example was only rejected by the `.props` file not
existing.
d5118ed2e5 Merge branch 'backport-vs-sdk-selection' into vs-sdk-selection
89b611ab32 VS: Select latest Windows SDK even when targeting Windows 8.1 and below
ae97d82e83 VS: Teach CMAKE_GENERATOR_PLATFORM to support Windows 8.1 SDK selection
15ff89654b VS: Teach CMAKE_GENERATOR_PLATFORM to use Windows 10 SDKs for older versions
bba1a23da9 VS: Consolidate Windows SDK major version selection dispatch
209973e510 VS: Do not print empty Windows SDK version when none is selected
ec6dd77053 Tests: Remove redundant condition in RunCMake.GeneratorPlatform test
4776a584ad Help: Add 3.27 release note on VS default SDK selection
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8697
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.
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`. Use `clang-format` version 15.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
Fixes: #24315
Since commit 1ab3881ec9 (cmake: Add options for parallel builds to
--build mode, 2018-04-14, v3.12.0-rc1~42^2), `cmake --build --parallel`
has added two options to the msbuild command line:
* `/m` enables inter-project parallelism in msbuild.
* `/p:CL_MPCount=1` suppresses intra-project parallelism in cl.
The latter was used to avoid `O(N^2)` compilation threads on `N`
processors. In practice however, projects often have many source files
in a few targets, so `--parallel` actually reduces parallelism.
Drop the latter option to restore intra-project parallelism.
Users can always add `-- /p:CL_MPCount=1` themselves.
Fixes: #20564
Enables the Global Visual Studio Versioned Generator to use two-part toolset versions,
if only one toolset has that version number. For example, (14.32 is specified when
14.32.32142 and 14.32.23242 are installed). This change also add a unique return code
and message if a two-part version is used when multiple matching versions are present.
Fixes: #23933
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
In `cmGlobalVisualStudio7Generator::WriteTargetsToSolution`, we skip
writing `ZERO_CHECK.proj` to solution file as the check in
`cmGlobalVisualStudioGenerator::IsInSolution` returns `false` for
`ZERO_CHECK`. However, we write ZERO_CHECK to ProjectDependencies for
external projects as there are no checks in
`cmGlobalVisualStudio71Generator::WriteExternalProject`.
Similar to `cmGlobalVisualStudioGenerator::IsInSolution`, we introduce
`IsDepInSolution(const std::string&)` which excludes `ZERO_CHECK.proj`
from being added to sln file for the cases where we have `ZERO_CHECK.proj`.
Fixes: #23708
Rename the booleans 's_ErrorOccured' and 's_FatalErrorOccured' to
's_ErrorOccurred' and 's_FatalErrorOccurred', respectively.
Rename the getters and setters to 'Get[Fatal]ErrorOccurred' and
'Set[Fatal]ErrorOccurred', and fix all uses across the codebase.
For VS 19 and above, switch the format of project file to
`VsProjectType::proj` for ZERO_CHECK target. The `ZERO_CHECK.proj`
consists of primitive MSBuild commands only and has no dependency on any
other targets or props files. This proj file is written as a
`ProjectReference` for other targets, but is not written to the sln
file.
Revert commit 925da7d428 (VS: Write ZERO_CHECK.proj for VS19 and above,
2021-12-24). Although its commit message was mistakenly not updated, it
implemented the change for VS 2017 and below too. Since it was merged,
I've discovered several subtle failures in nightly testing with VS 2017.
Revert the change pending further investigation.
d92469e572 Help: Clarify how package resolve mode is intended to be used
f320a31087 cmake --build: prioritize --resolve-package-references over preset
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6984
* Extend Visual Studio solution parser for reading build target
* Map solution build target to project build target (especially for Any CPU)
* Use C++ <optional> template instead of pointer return value for cmSlnData::GetProjectByGUID
Add fields to the VS generator to select a target framework.
Migrate the existing default for VS 12 .NET CF for Windows CE.
Report the values in `CMAKE_VS_*` variables and use them for
the CSharp compiler id project too.
Issue: #22849
