summaryrefslogtreecommitdiffstats
path: root/Source/cmGlobalVisualStudioVersionedGenerator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'backport-vs-sdk-selection' into vs-sdk-selectionBrad King2023-08-101-20/+0
|\
| * VS: Consolidate Windows SDK major version selection dispatchBrad King2023-08-101-20/+0
| | | | | | | | | | | | | | Make logic choosing between Windows 10 SDKs and the Windows 8.1 SDK easier to follow by consolidating it in the VS 14 generator. The only information we need from VS 15+ generators is whether the 8.1 SDK is installed.
* | strings: use `emplace_back` with `cmStrCat` argumentsBen Boeckel2023-07-281-2/+2
| |
* | strings: use character literals where possibleBen Boeckel2023-07-281-2/+2
| |
* | cmStrCat: use in Windows-specific sourcesBen Boeckel2023-07-281-67/+67
| |
* | strings: compare to static `string_view` instances in Windows-only codeBen Boeckel2023-07-271-4/+4
| |
* | Drop Visual Studio 11 2012 generatorBrad King2023-06-131-9/+0
|/ | | | This generator has been deprecated since CMake 3.25. Remove it.
* VS: Add support for C++ module internal partitions in VS 17.6 and newerBrad King2023-05-171-0/+16
| | | | | | | | 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.
* VS: Add CMAKE_GENERATOR_PLATFORM field to control Windows SDK selectionBrad King2023-04-051-1/+2
| | | | | | | Add a `version=` field to explicitly control the SDK version selection without relying on `CMAKE_SYSTEM_VERSION`. Fixes: #16713
* VS: Defer Windows SDK selection until CMAKE_GENERATOR_PLATFORM is knownBrad King2023-04-051-2/+3
| | | | Prepare to teach `CMAKE_GENERATOR_PLATFORM` to affect SDK selection.
* VS: Simplify logic to require SDK for Windows StoreBrad King2023-04-051-1/+1
| | | | | | Revise logic added by commit d7e863c1c1 (VS: Do not fail on Windows 10 with VS 2015 if no SDK is available, 2016-01-21, v3.4.3~1^2) to make the requirement decision locally and simplify signatures.
* VS: Add a variable to report the Visual Studio version build numberBrad King2022-12-071-0/+10
| | | | | | | | | | VS 2017 and above come with a Visual Studio Installer tool that tracks four-component Visual Studio version numbers. We already detect the VS version number because it is needed to make some generation decisions. Provide the number to projects in a `CMAKE_VS_VERSION_BUILD_NUMBER` variable so they can use it similarly. Fixes: #24230
* clang-tidy: fix `readability-isolate-declaration` lintsBen Boeckel2022-11-291-1/+2
|
* clang-tidy: fix `modernize-raw-string-literal` lintsBen Boeckel2022-11-291-2/+2
|
* clang-tidy: fix `readability-else-after-return` lintsBen Boeckel2022-11-291-16/+15
|
* clang-tidy: fix `modernize-use-auto` lintsBen Boeckel2022-11-291-1/+1
|
* clang-tidy: fix `modernize-use-nullptr` lintsBen Boeckel2022-11-291-3/+3
|
* Refactor: `cmGlobalGeneratorFactory::GetDocumentation` returns entryAlex Turbov2022-11-171-13/+12
| | | | | | | | | | Before, a documentation entry was in/out parameter. Now it's a normal return value. This also makes possible to eliminate defaulted default ctor for `cmDocumentationEntry` for C++ 11. Also, simplify `cmake::AppendGlobalGeneratorsDocumentation()`.
* VS: Restore support for two-part default toolset versionBrad King2022-11-031-18/+20
| | | | | | | | | | | | | Since commit f972e4fd3a (cmVSGenerator: Add support for two-part toolset versions for Visual Studio, 2022-09-01, v3.25.0-rc1~180^2), if a two-part toolset version is requested, we fail early if globbing finds no auxiliary toolsets with that version. This broke our existing support for detecting when the default toolset matches the two-part version requested. Fix the logic to ignore the two-part globbing results if they are empty so we fall through to checking the default version. Fixes: #24107
* Drop Visual Studio 10 2010 generatorBrad King2022-09-261-9/+0
| | | | This generator has been deprecated since CMake 3.22. Remove it.
* cmVSGenerator: Add support for two-part toolset versions for Visual StudioNicholas Sinlock2022-09-021-3/+34
| | | | | | | | | 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
* VS: Fix ARM64 host architecture detection in x86 binaryAnton Lapounov2022-08-011-1/+1
| | | | | | | Use the 64-bit registry view when we check whether Windows has the ARM64 version of the .NET Framework 4.x installed. Issue: #23755
* VS: Detect ARM64 host architecture at runtimeBrad King2022-07-271-36/+90
| | | | | | | | | | | | | | | | | | | | We use the host machine's architecture to select the `MSBuild.exe` binary variant, and the host toolset architecture. When CMake is compiled as `x64` or `x86` it may still run on ARM64 hosts. Detect the actual architecture of the host at runtime instead of relying on the architecture of CMake's own binary. The `arm64/MSBuild.exe` executable is an ARM64 .NET 4 application, which requires the ARM64 version of .NET Framework 4.8.1 to be installed on the machine. That version is not yet released for Windows 10; however, the `MSBuild/Current/Bin/arm64` directory is still created when installing Visual Studio 2022 (a user may upgrade to Windows 11 later). Use it only if the .NET Framework is installed. The `amd64/MSBuild.exe` executable cannot run on Windows 10 ARM64, but can run on Windows 11 ARM64. Fixes: #23755
* VS: Prefer ARM64 MSBuild on Windows ARM64 hostTommy Vercetti2022-06-211-0/+8
| | | | Fixes: #23629
* cmSystemTools: Fix 'ErrorOccurred' spellingFeRD (Frank Dana)2022-06-131-1/+1
| | | | | | | | 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.
* VS: ARM64 as default toolset architecture for ARM64 hostNiyas Sait2022-05-191-7/+11
| | | | Visual Studio 2022 17 Preview introduced a native ARM64 toolchain.
* Make cmGlobalVisualStudioGenerator::VSVersion enum classSumit Bhardwaj2022-01-251-57/+57
|
* Source: Fix possible IWYU warnings in Windows generatorsNAKAMURA Takumi2021-11-191-2/+11
|
* Merge topic 'vs-framework-version'Brad King2021-11-081-0/+6
|\ | | | | | | | | | | | | | | | | | | d51246c662 VS: Default TargetFrameworkVersion to v4.7.2 for VS 2022 f97f8537f3 VS: Model a default target framework e40cedddc0 cmVisualStudio10TargetGenerator: Refactor target framework selection 78782cc7dc cmGlobalVisualStudio8Generator: Refactor SetGeneratorPlatform Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !6699
| * VS: Default TargetFrameworkVersion to v4.7.2 for VS 2022Brad King2021-11-061-0/+6
| | | | | | | | | | | | | | | | MSBuild defaults to v4.0 but VS 2022 does not install it anymore. Explicitly specify a newer framework version by default. Use a version that VS 2022 installs without selecting a separate component. Fixes: #22835
* | VS: Allow CMAKE_GENERATOR_INSTANCE to specify portable instanceBrad King2021-10-291-1/+1
| | | | | | | | | | | | | | | | | | | | Previously the `CMAKE_GENERATOR_INSTANCE` value was used only to filter the instances reported by the Visual Studio Installer tool. If the specified install location is not known to the VS Installer, but the user provided a `version=` field, check for the installation directly on disk. Fixes: #21639, #22197
* | VS: Support version specification in CMAKE_GENERATOR_INSTANCEBrad King2021-10-291-7/+63
| |
* | VS: Parse comma-separated fields from CMAKE_GENERATOR_INSTANCEBrad King2021-10-291-2/+85
|/
* cmGlobalVisualStudioVersionedGenerator: Fix repeating SetGeneratorInstanceBrad King2021-10-261-1/+5
| | | | | | Fix logic added by commit 8917b8512f (cmGlobalVisualStudioVersionedGenerator: Allow repeating SetGeneratorInstance, 2021-10-20) to avoid repeating work.
* cmGlobalVisualStudio10Generator: Add method to find MSBuild earlyBrad King2021-10-201-0/+11
| | | | | Add a way to find MSBuild before the main `FindMakeProgram` code path has executed.
* cmGlobalVisualStudioVersionedGenerator: Allow repeating SetGeneratorInstanceBrad King2021-10-201-0/+6
|
* Use new AddCacheEntry signaturesMarc Chevrier2021-09-101-3/+3
|
* VS: Add special case for '-T version=14.29.16.11' under VS 16.11Brad King2021-08-191-0/+3
| | | | | | | | | | | Extend the table of special cases from commit 58a50a3a0a (VS: Fix '-T version=14.28' under VS 16.9, 2021-03-11, v3.19.7~1^2~1) and updated by commit a60141feaa (VS: Add special case for '-T version=14.29.16.10' under VS 16.10, 2021-05-27, v3.20.4~11^2). Add a special case for the name VS 17 will use for VS 16.11's default toolset, so that it can be used with VS 16.11 too. Issue: #21922
* VS: Update Visual Studio 17 2022 generator for Preview 2Brad King2021-07-151-2/+1
| | | | | | In particular, update to toolset `v143`. Fixes: #22339
* VS: Add ARM64EC to supported platforms for VS 16 and 17Brad King2021-06-291-1/+2
| | | | | | | | | In commit 4ea3a88625 (MSVC: Add support for targeting ARM64EC, 2020-12-30, v3.20.0-rc1~121^2) the `ARM64EC` platform was accidentally added to the list for VS 15 (2017) instead of VS 16 (2019). Its omission from the list of platforms was then repeated for VS 17 (2022). Issue: #21724
* VS: Use 64-bit MSBuild in VS 2022Brad King2021-06-251-0/+6
| | | | | | | | | | | | | Visual Studio 17 2022 is now a 64-bit native application. It places the 64-bit `MSBuild.exe` in the `PATH` of VS command prompts, so prefer it for this version and above. This was previously attempted for older VS versions, but reverted by commit f3cedf381e (VS: Revert "Use MSBuild matching toolset host architecture", 2019-03-12, v3.14.0~1^2). For now, do not use the 64-bit MSBuild for VS 16 and below. Fixes: #18219
* VS: Add Visual Studio 17 2022 generatorBrad King2021-06-251-0/+91
| | | | Fixes: #22339
* VS: Add support for Utf8Enconding when using VS 16.10+Gustavo Varo2021-06-171-0/+15
| | | | | | | On VS 16.10 Preview 2 or above, generate `UseUtf8Encoding` instead of `StdOutEncoding=UTF-8` in `.vcxproj` files. Fixes: #22032
* VS: Compare VS instance versions as stringsBrad King2021-06-171-7/+7
| | | | This makes the values more readable.
* cmGlobalVisualStudio10Generator: Adopt GetVSInstanceVersion methodBrad King2021-06-161-6/+11
| | | | Port from `cmGlobalVisualStudioVersionedGenerator`.
* VS: Add special case for '-T version=14.29.16.10' under VS 16.10Brad King2021-05-271-0/+3
| | | | | | | | | | | | | Extend the table of special cases from commit 58a50a3a0a (VS: Fix '-T version=14.28' under VS 16.9, 2021-03-11, v3.19.7~1^2~1). Add a special case for the name VS 16.11 will use for VS 16.10's default toolset, so that it can be used with VS 16.10 too. Using '-T version=14.29.16.10' actually works under VS 16.10 without this change, but only because there is only one 14.29 toolset so the two-component prefix happens to match the right one. Make it explicit. Issue: #21922
* Merge topic 'vs-toolset-version' into release-3.20Brad King2021-03-151-40/+87
|\ | | | | | | | | | | | | | | | | 30c835428f VS: Accept and translate '-T version=' values with three components 58a50a3a0a VS: Fix '-T version=14.28' under VS 16.9 09f59da7f0 cmGlobalVisualStudioVersionedGenerator: Clarify local variable name Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5903
| * VS: Accept and translate '-T version=' values with three componentsBrad King2021-03-121-0/+37
| | | | | | | | | | | | | | | | The VS 16.8 and VS 16.9 toolset versions differ only in their third component. The `vcvarsall` option `-vcvars_ver=` accepts a three component version, so accept this format for VS toolset selection too. Issue: #21922
| * VS: Fix '-T version=14.28' under VS 16.9Brad King2021-03-121-40/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CMake accepts the toolset version that is default in the current VS version by matching the name later VS versions will use for the SxS props files. It predicts the future name based on the first two components of the current VS version's default toolset. However, this heuristic breaks naming the VS 16.8 toolset version 14.28 under VS 16.9 because the latter's default toolset version is 14.28.29910, which did not increment the second version component (unprecedented in VS). Fix this by always using the requested version's SxS props file when it exists, even if it matches the first two components of the current VS version's default toolset. Also add a special case for the name VS 16.10 will use for VS 16.9's default toolset, so that it can be used with VS 16.9 too. Fixes: #21922
* | Merge topic 'msvc-arm64ec-platform-support'Brad King2021-01-221-0/+1
|\ \ | |/ |/| | | | | | | | | 4ea3a88625 MSVC: Add support for targeting ARM64EC Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5708
generated by cgit v0.12 at 2025-01-10 03:37:41 (GMT)