summaryrefslogtreecommitdiffstats
path: root/Source/cmGlobalVisualStudio10Generator.h
Commit message (Collapse)AuthorAgeFilesLines
* Drop Visual Studio 10 2010 generatorBrad King2022-09-261-12/+2
| | | | 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-1/+2
| | | | | | | | | 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: Revert "Write ZERO_CHECK.proj for VS19 and above"Brad King2022-07-221-4/+0
| | | | | | | | | | | | | | | 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
* VS: Exclude ZERO_CHECK.proj from .sln for include_external_msprojectSumit Bhardwaj2022-07-201-0/+2
| | | | | | | | | | | | | | | 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
* VS: Write ZERO_CHECK.proj for VS19 and aboveSumit Bhardwaj2022-02-211-0/+2
| | | | | | | | | 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.
* VS: Revert "Write ZERO_CHECK.proj for VS19 and above"Brad King2022-02-171-2/+0
| | | | | | | | 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.
* VS: Write ZERO_CHECK.proj for VS19 and aboveSumit Bhardwaj2022-02-121-0/+2
| | | | | Use VsProjectType::proj as the file format for ZERO_CHECK and write ZERO_CHECK.proj as a msbuild dependency for other projects.
* cmGlobalVisualStudio10Generator: Auto restore NuGet packages.Carsten Rudolph2022-01-221-0/+2
|
* cmBuildOptions: Split build arguments into separate object.Carsten Rudolph2022-01-221-1/+2
|
* Source: Fix possible IWYU warnings in Windows generatorsNAKAMURA Takumi2021-11-191-0/+11
|
* cmGlobalVisualStudio10Generator: Add method to find MSBuild earlyBrad King2021-10-201-0/+2
| | | | | Add a way to find MSBuild before the main `FindMakeProgram` code path has executed.
* cmGlobalGenerator: Add method to check if generator is at least VS 10Brad King2021-10-201-0/+2
|
* cmGlobalVisualStudio10Generator: Allow subclasses to reset MSBuild searchBrad King2021-10-201-1/+1
| | | | While at it, convert to inline initialization.
* VS: Add support for Utf8Enconding when using VS 16.10+Gustavo Varo2021-06-171-0/+2
| | | | | | | 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-4/+1
| | | | This makes the values more readable.
* cmGlobalVisualStudio10Generator: Adopt GetVSInstanceVersion methodBrad King2021-06-161-0/+5
| | | | Port from `cmGlobalVisualStudioVersionedGenerator`.
* VS: Add a mostly-undocumented hook to load custom JSON flag tablesBrad King2021-03-221-0/+2
| | | | | | | | | | | The names and formats of our VS flag tables are internal implementation details. However, some institutions need to maintain support for non-public VS platforms and toolsets. Provide a hook that their projects can use to load custom flag table files. This helps avoid distributing a custom CMake package within such institutions. Document the hook itself, but explicitly specify that the files the hook loads are not considered a stable interface.
* VS: switch to new folder structure while keeping the old one workingMarcel Ritzschke2021-03-181-0/+9
| | | | Fixes: #21170
* Merge topic 'vs-toolset-version'Brad King2021-03-151-7/+15
|\ | | | | | | | | | | | | | | | | 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: Fix '-T version=14.28' under VS 16.9Brad King2021-03-121-7/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | cmGlobalVisualStudio10Generator: Generalize flag table lookup interfaceBrad King2021-03-051-0/+6
| |
* | cmGlobalVisualStudio10Generator: Clarify LoadFlagTable argument nameBrad King2021-03-051-1/+1
| |
* | cmGlobalVisualStudio10Generator: Remove redundant argumentsBrad King2021-03-051-1/+0
| |
* | cmGlobalVisualStudio10Generator: Remove redundant argumentsBrad King2021-03-051-6/+6
| |
* | cmGlobalVisualStudio10Generator: Clarify method nameBrad King2021-03-051-1/+1
| |
* | cmGlobalVisualStudio10Generator: Remove unused flag table method argumentBrad King2021-03-051-14/+7
| |
* | cmGlobalVisualStudio10Generator: Adopt flag table name methodsBrad King2021-03-051-2/+15
|/ | | | Migrate them from `cmVisualStudio10ToolsetOptions`.
* Modernize: Use #pragma once in all header filesKitware Robot2020-09-031-3/+1
| | | | | | | | | | | | | | | | #pragma once is a widely supported compiler pragma, even though it is not part of the C++ standard. Many of the issues keeping #pragma once from being standardized (distributed filesystems, build farms, hard links, etc.) do not apply to CMake - it is easy to build CMake on a single machine. CMake also does not install any header files which can be consumed by other projects (though cmCPluginAPI.h has been deliberately omitted from this conversion in case anyone is still using it.) Finally, #pragma once has been required to build CMake since at least August 2017 (7f29bbe6 enabled server mode unconditionally, which had been using #pragma once since September 2016 (b13d3e0d)). The fact that we now require C++11 filters out old compilers, and it is unlikely that there is a compiler which supports C++11 but does not support #pragma once.
* Visual Studio: Add Android supportKyle Edwards2020-06-241-0/+16
|
* cmGlobalVisualStudio10Generator: Move variable initialization to headerKyle Edwards2020-06-181-3/+3
|
* VS: Use StdOutEncoding for VS 16.7 Preview 3 and aboveJustin Goshi2020-06-031-0/+2
| | | | | | | | | | | | | | | | | 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
* Merge topic 'vs-version-for-unity'Brad King2020-02-051-0/+3
|\ | | | | | | | | | | | | 9135954e2f VS: Do not use native unity builds on VS 2017 versions less than 15.8 Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !4324
| * VS: Do not use native unity builds on VS 2017 versions less than 15.8Brad King2020-02-041-0/+3
| | | | | | | | | | | | | | | | VS 2017 version 15.8 introduced support for unity builds implemented in part by the `$(VCTargetsPath)/Microsoft.Cpp.Unity.targets` file. Do not enable unity builds on VS 15 versions that do not have that file. Fixes: #20284
* | GlobalGenerator family: modernize memory managementMarc Chevrier2020-01-071-1/+1
| |
* | cmLocalGenerator: modernize memory managementMarc Chevrier2019-12-091-1/+4
| |
* | VS: Add support to override VCTargetsPath through toolsetAlexander Boczar2019-10-151-0/+5
| | | | | | | | Fixes: #19708
* | cmake: Teach --build mode to load CMAKE_GENERATOR_TOOLSETAlexander Boczar2019-10-151-1/+2
|/ | | | | Extend the `cmGlobalGenerator::SetGeneratorToolset` signature to indicate when it is called from `cmake::build`.
* cuda: Extend toolset argument to accept pathBenjamin Wozniak2019-08-271-0/+5
| | | | | | | | Previously cuda could only be used with cmake if it is installed globally on the system. Sometimes this is not possible (eg docker, packaging with conan, etc.). Thus the cuda toolset argument is extended to take a path to a cuda install directory.
* VS: Factor out helper to compute ApplicationTypeRevisionBrad King2019-05-211-0/+3
| | | | This is the first two components of `CMAKE_SYSTEM_VERSION`.
* Fix invalid ///! doxygen comment line startsSebastian Holtermann2019-03-311-1/+1
| | | | | In various places `///!` was used to start a comment line. This is not valid Doygen syntax. This patch replaces `///!` comment starts with `//!`.
* cmake: Teach --build mode to support multiple targetsBartosz Kosiorek2019-03-051-9/+6
| | | | Fixes: #16136
* Merge topic 'add_consistent_verbose_build_flag'Brad King2019-01-291-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | 66801f4d40 cmake: Add tests for verbose output to --build mode 439fe2e253 cmake: Add options for verbose output to --build mode 638667efa2 cmake: cmcmd.cxx fix "The arguments are" comments 3ca4402966 ctest: Fix --build-and-test without --build-target on Xcode cb6c233ecc cmake: Add -hideShellScriptEnvironment xcodebuild option 1a45266cb5 cmGlobalGenerator: Add a class that represent the build command Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !2708
| * cmGlobalGenerator: Add a class that represent the build commandRobert Maynard2019-01-251-1/+1
| | | | | | | | | | | | This refactors a std::vector<std::string> into a class so that we can extend the features to represent things such as multiple chained commands in the future.
* | VS: Teach VS 2019 generator to select host tools matching host archBrad King2019-01-281-0/+2
|/ | | | | This generator is new so we can introduce the long-desired behavior of selecting ``host=x64`` tools by default on x64 hosts.
* Merge topic 'support_per_toolset_json_flags'Brad King2019-01-161-1/+3
|\ | | | | | | | | | | | | c8ba777f6d GlobalVisualStudio10Generator: Support non-standard toolset json flag files. Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !2772
| * GlobalVisualStudio10Generator: Support non-standard toolset json flag files.Stephan Szabo2019-01-031-1/+3
| | | | | | | | | | | | If given a toolset that does not have an explicit mapping in cmVisualStudio10ToolsetOptions, check for a json flag file using the toolset name before trying the default toolset for the generator.
* | VS: Clarify global generator constructor interfaceBrad King2019-01-101-2/+5
| | | | | | | | | | | | Make the constructors protected since they should be produced through factories. Also rename `platform{ => InGenerator}Name` to clarify the meaning of the argument.
* | VS: Convert WriteSLNHeader to non-virtual lookup tableBrad King2019-01-101-1/+0
| |
* | VS: Convert GetIDEVersion to non-virtual table lookupBrad King2019-01-101-2/+0
| |
* | VS: Convert GetToolsVersion to non-virtual table lookupBrad King2019-01-101-1/+1
| |
generated by cgit v0.12 at 2025-01-31 05:34:02 (GMT)