summaryrefslogtreecommitdiffstats
path: root/Source/cmGlobalVisualStudio10Generator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* cmake: Add options for verbose output to --build modeFlorian Maushart2019-01-281-0/+4
| | | | | | | | | | | | While we already support `VERBOSE` environment variable and `CMAKE_VERBOSE_MAKEFILE` cached variable, add `-v` and `--verbose` command line options to be able to activate verbose output directly from CMake's build tool mode command line. Also make `msbuild` honor the verbosity setting. `xcodebuild` still doesn't honor the verbosity setting as it will need a policy added and reworking of cmGlobalGenerator and cmsys to support multiple command invocation.
* cmGlobalGenerator: Add a class that represent the build commandRobert Maynard2019-01-251-14/+17
| | | | | | 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.
* Add global generator factory method to get default platform nameBrad King2019-01-181-0/+2
|
* Add global generator factory method to get list of known platformsBrad King2019-01-181-0/+9
| | | | | | | | | 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-1/+9
| | | | | | 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.
* Merge topic 'support_per_toolset_json_flags'Brad King2019-01-161-37/+79
|\ | | | | | | | | | | | | 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-37/+79
| | | | | | | | | | | | 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.
* | Factor out enum MessageType into dedicated headerBruno Manganelli2019-01-161-16/+17
| | | | | | | | Reduce the number of files relying on `cmake.h`.
* | VS: Add Visual Studio 16 2019 generatorBrad King2019-01-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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: Track explicitly when platform is specified in generator nameBrad King2019-01-101-2/+2
| |
* | VS: Clarify global generator constructor interfaceBrad King2019-01-101-2/+3
| | | | | | | | | | | | 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-10/+0
| |
* | VS: Convert GetToolsVersion to non-virtual table lookupBrad King2019-01-101-0/+21
|/
* Replace header flag tables with json readingStephan Szabo2018-11-281-39/+140
| | | | | Stop loading flag tables from header files and instead load the flag table information from json files in Templates/MSBuild/FlagTables.
* VS: Pass platform when invoking MSBuildBrad King2018-09-251-0/+1
| | | | | | | | | | MSBuild expects a `/p:Platform=...` argument to tell it which platform to build among those in the `.vcxproj` files. We have not historically had to do this because we generate only one platform. However, when a project uses `include_external_msproject` the included project file may have other platforms. Fixes: #18308
* cmLocalGenerator: return directories as const std::string&Vitaly Stakhovsky2018-08-271-1/+1
|
* VS: Allow toolset version selection to specify default toolsetBasil Fierz2018-06-241-18/+31
| | | | | | | | | | Teach the feature added by commit v3.12.0-rc1~38^2 (VS: Add option to select the version of the toolset used by VS 2017, 2018-05-19) to accept the default toolset version in addition to older versions. If the default toolset version is supplied, simply clear it so the default will be used. Fixes: #18107
* Merge topic 'vs-toolset-version'Brad King2018-05-301-0/+85
|\ | | | | | | | | | | | | | | 5f13168419 VS: Add option to select the version of the toolset used by VS 2017 Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Francisco Facioni <fran6co@gmail.com> Merge-request: !2093
| * VS: Add option to select the version of the toolset used by VS 2017Basil Fierz2018-05-291-0/+85
| | | | | | | | | | | | | | | | Add new `version=` parameter in the toolset setting to select the version. Add variable `CMAKE_VS_PLATFORM_TOOLSET_VERSION` to hold the version, if one is set (blank indicates default). Fixes: #17549
* | cmake: Add options for parallel builds to --build modeFlorian Maushart2018-05-251-2/+14
|/ | | | | | | While we already support `cmake --build . -- -j`, the options after `--` are specific to the native build tool. Add new options `--parallel [<N>]` and `-j [<N>]` to abstract this and map to the proper option for the native build tool.
* cmGlobalVisualStudio10Generator: Use cmXMLWriter RAII helpersVitaly Stakhovsky2018-03-091-115/+78
| | | | | This simplifies our XML generation code and avoids the need to disable clang-format.
* VS: Use range-based 'for' loops in generator codeVitaly Stakhovsky2017-12-211-6/+6
| | | | Use `auto` for complex types.
* VS: Emit "utf-8" encoding as lowercase in .vcxproj headersVitaly Stakhovsky2017-12-141-0/+5
| | | | Match the XML preamble generated by VS 2010 and later.
* Merge topic 'string-clear'Brad King2017-09-191-2/+2
|\ | | | | | | | | | | | | 5db3aac1 Meta: replace empty-string assignments with `clear()`. Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !1276
| * Meta: replace empty-string assignments with `clear()`.Pavel Solodovnikov2017-09-151-2/+2
| |
* | Use C++11 override instead of CM_OVERRIDEBrad King2017-09-151-5/+5
|/ | | | | | | | We now require C++11 support including `override`. Drop use of the old compatibility macro. Convert references as follows: git grep -l CM_OVERRIDE -- '*.h' '*.hxx' '*.cxx' | xargs sed -i 's/CM_OVERRIDE/override/g'
* MSVC: Add support for ARM64 architectureMinmin Gong2017-09-121-1/+6
| | | | | | Visual Studio 15.4 adds support for this architecture. Fixes: #17213
* Use C++11 nullptrDaniel Pfeifer2017-08-241-9/+9
|
* VS: Fix VCTargetsPath detectionBrad King2017-08-031-0/+1
| | | | | | | | In some environments MSBuild chooses the `Release` configuration even though only `Debug` is available in our detection project. Force use of the `Debug` configuration with a command-line option. Fixes: #17118
* VS: Fix GenerateDebugInformation values for v140 and v141 toolsetsBrad King2017-06-281-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When VS 2015 was first released, its new v140 toolset came with a `link.xml` file that changed the `GenerateDebugInformation` boolean (`false` and `true`) value from earlier toolsets to an enumeration consisting of the possible values `No`, `Debug`, and `DebugFastLink`. We first adapted to this in commit v3.4.2~2^2 (VS: Fix VS 2015 .vcxproj file value for GenerateDebugInformation, 2016-01-08), but that broke older toolsets that still expected the boolean. Then commit v3.6.0-rc1~295^2~1 (VS: Fix VS 2015 .vcxproj debug setting for older toolsets, 2016-02-24) added a hack to fix up the value based on the toolset in use. Several follow-up commits fixed this for more older toolsets because our flag table was at the time based on the generator in use rather than the toolset in use. Since commit v3.8.0-rc1~396^2 (VS: Choose flag map based on the toolset name, 2016-10-17) we use a flag table based on the toolset, so the fixup hack should not be needed. We had to keep it around only due to our default value for GenerateDebugInformation (`false` or `No`) still being based on the generator instead of the toolset. A VS 2015 update was released that changed the v140 toolset `link.xml` file back to using `false` and `true` for the `GenerateDebugInformation` enumeration variants previously known as `No` and `Debug`. In order to know which pair to use, we need to parse the `link.xml` file for the current toolset. Switch back to using `false` and `true` unconditionally in our `GenerateDebugInformation` flag table entries and default value. With that plus the toolset-based flag table, we now get incorrect values for `GenerateDebugInformation` only when using a v140 toolset from an older VS 2015 installation. Detect this case by parsing `link.xml` and add special logic to convert `false` and `true` to `No` and `Debug` to satisfy the older toolset specification. Inspired-by: Ian Hojnicki <nullref@live.com> Fixes: #17020
* VS: Fix .vcxproj ProjectGuid element caseBrad King2017-05-091-2/+2
| | | | | | | | The `.vcxproj` file format expects `ProjectGuid`, not `ProjectGUID`. The latter is expected by `.vcproj` files from VS 2008, so this was likely a typo when the VS 2010 generator was first introduced. Fixes: #11968
* Use quotes for non-system includesDaniel Pfeifer2017-04-111-3/+3
| | | | | | | | | | | | | Automate with: git grep -l '#include <cm_' -- Source \ | xargs sed -i 's/#include <\(cm_.*\)>/#include "\1"/g' git grep -l '#include <cmsys/' -- Source \ | xargs sed -i 's/#include <\(cmsys\/.*\)>/#include "\1"/g' git grep -l '#include <cm[A-Z]' -- Source \ | xargs sed -i 's/#include <\(cm[A-Z].*\)>/#include "\1"/g'
* VS: Add placeholder CUDA flag tablesBrad King2017-03-101-0/+15
| | | | | | | The CUDA Toolkit's VS integration defines abstractions for both options to `nvcc` and options to pass through `-Xcompiler` to the host MSVC. We need a separate flag table to parse each set of flags into the corresponding abstractions. Add empty placeholders for these tables.
* VS: Record in global generator whether CUDA is enabledBrad King2017-03-101-0/+4
|
* VS: Select highest available CUDA toolset by defaultBrad King2017-03-101-0/+27
| | | | | If `CMAKE_GENERATOR_TOOLSET` does not have a `cuda=...` field then find available CUDA toolsets and choose the highest version.
* VS: Provide an option to specify CUDA toolset versionBrad King2017-03-101-2/+21
| | | | | | | | The NVIDIA CUDA Toolkit provides MSBuild toolset files for integration with Visual Studio. Multiple versions may be installed so we need a way to tell our VS generators which CUDA toolset to use. Extend the `CMAKE_GENERATOR_TOOLSET` specification to provide a `cuda=...` field specifying the version number.
* VS: Find the MSBuild value for VCTargetsPathBrad King2017-03-101-0/+212
| | | | | | Run MSBuild on a simple `.vcxproj` file to extract the location of the toolset definitions. This will later be useful for looking at available BuildCustomizations.
* VS: Refactor generator toolset parsingBrad King2017-02-151-13/+69
| | | | | | | | | | | | | | | | | We parse `CMAKE_GENERATOR_TOOLSET` values of the forms: * `toolset` * `toolset,host=x64` * `host=x64` Generalize the parsing to support the forms: * `toolset` * `toolset[,key=value]*` * `key=value[,key=value]*` Disallow duplicate keys. Require all but the first field to be of `key=value` form.
* VS: Add support for ASM_NASM languageEvgeny Fimochkin2017-02-071-0/+14
| | | | Fixes: #16469
* VS: Use Visual Studio Installer to locate VS 2017Iyyappa Murugandi2016-12-161-14/+0
| | | | | | | | VS 2017 and later may no longer populate the Windows Registry entries CMake has traditionally used to find the VS installations. This is because VS now supports having multiple installations of the same version. The Visual Studio Installer tool provides a COM interface we can query to locate installations.
* Merge branch 'vs-fix-standalone-Windows7.1SDK-toolset' into ↵Brad King2016-12-071-1/+10
|\ | | | | | | vs-fix-standalone-Windows7.1SDK-toolset-for-master
| * VS: Fix standalone Windows7.1SDK toolset selectionBrad King2016-12-071-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit v3.7.0-rc1~142^2~1 (VS: Explicitly default to v100 toolset in Visual Studio 2010, 2016-07-21) we prefer to always set a platform toolset explicitly so that `CMAKE_VS_PLATFORM_TOOLSET` can be reported. However, the `v100` default for the VS 10 generator is not appropriate for all environments. We fixed support for VS 2010 Express Edition in commit v3.7.0-rc1~142^2 (VS: Do not default to missing v100 64-bit toolset on VS 2010 Express, 2016-09-09). Fix support for the standalone Windows7.1SDK toolset environment by recognizing the `PlatformToolset` environment variable that it sets to `Windows7.1SDK` and using this as our default toolset instead. Closes: #16483
* | VS: Add flag tables for C#Michael Stürmer2016-12-011-0/+11
| | | | | | | | | | | | | | Add these (currently unused) tables in preparation for `.csproj` generation support. Populate the tables for every version with a set of initial values that work well for me with VS 12 and VS 14. Later we may need to generate them more thoroughly from MSBuild `.xml` files.
* | iwyu: Fix VisualStudio specific issuesDaniel Pfeifer2016-11-281-2/+1
| |
* | Merge topic 'vs-fix-no-toolset'Brad King2016-10-271-1/+5
|\ \ | | | | | | | | | | | | 0caca40f VS: Fix use of `Windows7.1SDK` 64-bit toolset with VS 2010 Express
| * | VS: Fix use of `Windows7.1SDK` 64-bit toolset with VS 2010 ExpressBrad King2016-10-271-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Refactoring in commit 584ab528 (VS: Add internal API to get platform toolset as string, 2016-10-18) accidentally changed the semantics of the original `cmGlobalVisualStudio10Generator::GetPlatformToolset` implementation to return a pointer to an empty string instead of `nullptr` when no toolset is configured. This broke cases that tested for `nullptr` to detect the lack of any specific toolset, such as the call in `Find64BitTools`. Restore the `nullptr` return in this case.
* | | VS: Choose flag map based on the toolset nameDon Olmstead2016-10-251-5/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | MSBuild interprets the `.vcxproj` content based on the `PlatformToolset` setting, so our reverse mapping needs to be based on that setting too. For VS 2010 and above, choose the flag map to match the toolset name rather than the generator VS version. Issue: #16153
* | | VS: Move toolset flag table lookup to global generatorDon Olmstead2016-10-251-0/+35
|/ / | | | | | | | | Move `Get*FlagTable` methods to the global generator and have each VS generator version pre-populate its default flag table.
* | VS: Add internal API to get platform toolset as stringBrad King2016-10-251-3/+10
| |
* | cmGlobalGenerator: Allow FindMakeProgram to failBrad King2016-10-201-2/+5
| | | | | | | | | | Revise its signature to return `bool` so that it can fail and abort configuration early.
generated by cgit v0.12 at 2025-01-07 22:08:13 (GMT)