summaryrefslogtreecommitdiffstats
path: root/Source/cmGlobalVisualStudioVersionedGenerator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* 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
| * VS: Fix x64 host recognition by x86 cmake processBrad King2019-03-141-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | In commit 57e48f16f2 (VS: Add Visual Studio 16 2019 generator, 2019-01-09, v3.14.0-rc1~150^2) and commit 0fd742a6ff (VS: Teach VS 2019 generator to select host tools matching host arch, 2019-01-28, v3.14.0-rc1~63^2) we intended to select the `x64` target architecture and `x64` host tools by default on x64 host machines. Fix detection of a x64 host when CMake itself is a 32-bit x86 process. The KWSys SystemInformation `Is64Bits` member is not set correctly, which led to this bug. Pending investigation on the KWSys side, simply test ourselves via `IsWow64Process`.
* | Merge topic 'revert-vs-msbuild-arch'Brad King2019-03-131-12/+0
|\ \ | |/ | | | | | | | | | | f3cedf381e VS: Revert "Use MSBuild matching toolset host architecture" Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !3090
| * VS: Revert "Use MSBuild matching toolset host architecture"Brad King2019-03-121-12/+0
| | | | | | | | | | | | | | | | | | | | | | Revert commit da402a081b (VS: Use MSBuild matching toolset host architecture, 2019-01-28, v3.14.0-rc1~50^2). Multiple people have reported that the 64-bit `amd64/msbuild` tool fails in cases that the 32-bit `msbuild` works. Drop our change pending further investigation and hopefully a fix to VS. Fixes: #18904, #19037 Issue: #18219
* | Fix missing `override`Vitaly Stakhovsky2019-03-051-3/+3
|/
* VS: Tell VS 2019 to use Windows SDK 8.1 explicitly when neededBrad King2019-02-191-0/+6
| | | | | | | | VS 2019 does not default to the 8.1 SDK as VS 2017 and VS 2015 did. When `CMAKE_SYSTEM_VERSION` is 8.1 or lower, select the 8.1 SDK explicitly. Fixes: #18927
* VS: Fix validation of Windows 8.1 SDKBrad King2019-02-141-1/+2
| | | | | | | | The check added by commit 0a29a31161 (VS2017: Verify Windows 8.1 SDK before using it, 2017-04-25, v3.8.1~2^2) used the wrong path to `windows.h` within the SDK, leading to it never being detected. Fixes: #18923
* VS: Use MSBuild matching toolset host architectureBrad King2019-01-291-0/+12
| | | | | | | | VS 2017 and VS 2019 provide `amd64/MSBuild.exe` variants next to their `MSBuild.exe` tools. When the 64-bit host toolchain is selected (e.g. via `host=x64`), select the 64-bit MSBuild too. Fixes: #18219
* VS: Teach VS 2019 generator to select host tools matching host archBrad King2019-01-281-0/+18
| | | | | This generator is new so we can introduce the long-desired behavior of selecting ``host=x64`` tools by default on x64 hosts.
* VS: Remove stray semicolons from VS 2019 implementationBrad King2019-01-281-3/+3
|
* VS: Update for Visual Studio 2019 Preview 2Brad King2019-01-241-2/+1
| | | | | | The toolset is now called `v142`. Use matching flag tables. Fixes: #18834
* Add global generator factory method to get default platform nameBrad King2019-01-181-0/+7
|
* Add global generator factory method to get list of known platformsBrad King2019-01-181-0/+20
| | | | | | | | | Add a `cmGlobalGeneratorFactory::GetKnownPlatforms` method to return a list of known possible values for `CMAKE_GENERATOR_PLATFORM`. Implement the method for each generator by referencing the list of possible values documented in `Help/generator/*.rst` for it. Co-Author: Julien Jomier <julien.jomier@kitware.com>
* Split global generator factory list with and without platformsBrad King2019-01-181-2/+17
| | | | | | Replace `cmGlobalGeneratorFactory::GetGenerators` with a pair of methods to split the list of generator names into those that have platforms in the name and those that do not.
* VS: Factor out helper function to compute host platform nameBrad King2019-01-181-10/+15
|
generated by cgit v0.12 at 2025-01-03 23:41:19 (GMT)