summaryrefslogtreecommitdiffstats
path: root/Source/cmGlobalVisualStudioVersionedGenerator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* Factor out enum MessageType into dedicated headerBruno Manganelli2019-01-161-2/+3
| | | | Reduce the number of files relying on `cmake.h`.
* VS: Add Visual Studio 16 2019 generatorBrad King2019-01-111-6/+120
| | | | | | | | | | | | Add this generator *without* support for specifying the target architecture in the generator name. cmake-gui will be taught to provide a field for this, and command-line builds can use -A. Also, teach this generator to select a default target architecture based on the host architecture. Fixes: #18689 Inspired-by: Egor Pugin <egor.pugin@gmail.com>
* VS: Parameterize VS 2017 generator to support future versionsBrad King2019-01-111-8/+41
|
* VS: Rename VS 2017 generator sources to be version-independentBrad King2019-01-111-0/+291
Rename `cmGlobalVisualStudio{15 => Versioned}Generator`. Rename `Factory` to `Factory15` since that part still needs to be version-specific.
generated by cgit v0.12 at 2025-01-03 22:56:19 (GMT)