summaryrefslogtreecommitdiffstats
path: root/Source/cmGlobalVisualStudioVersionedGenerator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* 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
| * MSVC: Add support for targeting ARM64ECMoyo Okeremi 😊2021-01-211-0/+1
| |
* | VS: Generalize Win10 max SDK version to all VS generatorsjonathan molinatto2021-01-201-1/+2
|/ | | | | | | | | | | The `CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION_MAXIMUM` variable added in CMake 3.19 by commit ba497111f6 (VS: Add option for custom Win10 SDK version maximum, 2020-08-20, v3.19.0-rc1~262^2) was documented as if it worked for all generators but implemented only to override CMake's builtin default for the VS 2015 max SDK version. Generalize the variable to set a custom max SDK version for later VS versions too. Fixes: #21720
* Refactor: Add allowArch parameter to cmake::CreateGlobalGenerator()Kyle Edwards2020-10-051-3/+3
|
* VS: Add option for custom Win10 SDK version maximumjonathan molinatto2020-08-251-2/+2
| | | | | | | | | | | | | | | | | | | | | Since commit 83ddc4d289 (VS: Do not select a Windows SDK too high for current VS version, 2017-08-07, v3.13.0-rc1~72^2~2) we enforce a maximum SDK version for the VS 2015 generator. The blog post linked in the original commit is no longer available, but it can be seen here: * https://web.archive.org/web/20190108032520/https://blogs.msdn.microsoft.com/chuckw/2018/10/02/windows-10-october-2018-update/ In particular, it states: > VS 2015 Users: The Windows 10 SDK (15063, 16299, 17134, 17763) > is officially only supported for VS 2017. However, in some circumstances a higher version can be used. Add a `CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION_MAXIMUM` to override the generator's default maximum SDK version. Fixes: #20633
* Visual Studio: Add Android supportKyle Edwards2020-06-241-0/+38
|
* VS: Use StdOutEncoding for VS 16.7 Preview 3 and aboveJustin Goshi2020-06-031-0/+15
| | | | | | | | | | | | | | | | | VS 16.6 added a `StdOutEncoding` setting for custom commands to tell MSBuild that the output is encoded as UTF-8. In commit bc877a7e94 (Add support to indicate UTF-8 custom command pipe output encoding, 2020-04-08) CMake learned to add the setting in anticipation of the VS 16.6 release. However, when 16.6 was released it had a bug in the implementation of custom tasks with StdOutEncoding enabled that was exposed by our test suite. In commit 5058fb5401 (VS: Drop StdOutEncoding with VS 16.6 pending investigation, 2020-05-29) we disabled the setting pending investigation. The problem is fixed in VS 16.7 Preview 3, so restore use of the setting when a VS instance of at least that version is detected. Fixes: #20769
* VS: Extract instance version from VS InstallerJustin Goshi2020-06-031-0/+6
|
* GlobalGenerator family: modernize memory managementMarc Chevrier2020-01-071-21/+25
|
* VS: Fix support for v142 toolset minor versions in VS 16.5+Brad King2019-12-121-9/+14
| | | | | | | | | | The fix in commit 5117389931 (VS: Fix support for v142 toolset minor versions, 2019-10-01, v3.16.0-rc1~32^2) worked around a bug in VS's placement of toolset files. VS 16.5 will fix that bug and restore the original pattern for locations of toolset files. Update our logic to look for both possibilities. Issue: #19779
* VS: Fix support for v142 toolset minor versionsBrad King2019-10-011-1/+3
| | | | | | | | When using `-T v142,version=14.22` the `.props` file location is different starting with version `14.20` than it was in `14.16` and below. Adapt the path based on the version. Fixes: #19779
* Merge topic 'vs2019-wow64'Brad King2019-03-151-5/+10
|\ | | | | | | | | | | | | 5c50eeaffc VS: Fix x64 host recognition by x86 cmake process Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !3102
generated by cgit v0.12 at 2025-01-04 00:27:54 (GMT)