summaryrefslogtreecommitdiffstats
path: root/Source/cmGlobalVisualStudio10Generator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* | VS: Provide an option to use x64 host toolsBrad King2016-10-141-1/+36
|/ | | | | | | | | | Visual Studio provides toolchains that are themselves built for 32-bit or 64-bit host architectures. By default it uses the 32-bit tools, but it can be told to prefer the 64-bit tools on 64-bit hosts. Extend the `CMAKE_GENERATOR_TOOLSET` specification to provide a way to request use of the 64-bit host tools. Closes: #15622
* Simplify CMake per-source license noticesBrad King2016-09-271-11/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Per-source copyright/license notice headers that spell out copyright holder names and years are hard to maintain and often out-of-date or plain wrong. Precise contributor information is already maintained automatically by the version control tool. Ultimately it is the receiver of a file who is responsible for determining its licensing status, and per-source notices are merely a convenience. Therefore it is simpler and more accurate for each source to have a generic notice of the license name and references to more detailed information on copyright holders and full license terms. Our `Copyright.txt` file now contains a list of Contributors whose names appeared source-level copyright notices. It also references version control history for more precise information. Therefore we no longer need to spell out the list of Contributors in each source file notice. Replace CMake per-source copyright/license notice headers with a short description of the license and links to `Copyright.txt` and online information available from "https://cmake.org/licensing". The online URL also handles cases of modules being copied out of our source into other projects, so we can drop our notices about replacing links with full license text. Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority of the replacements mechanically. Manually fix up shebang lines and trailing newlines in a few files. Manually update the notices in a few files that the script does not handle.
* Merge topic 'vs-default-v100'Brad King2016-09-121-0/+4
|\ | | | | | | | | 861f1b3d VS: Do not default to missing v100 64-bit toolset on VS 2010 Express
| * VS: Do not default to missing v100 64-bit toolset on VS 2010 ExpressBrad King2016-09-091-0/+4
| | | | | | | | | | | | | | | | Since commit 059c230d (VS: Explicitly default to v100 toolset in Visual Studio 2010, 2016-07-21) the VS 2010 generator now correctly defaults to the v100 toolset instead of no toolset. However, this broke our logic for defaulting to the `Windows7.1SDK` toolset for 64-bit builds on VS 2010 Express. Fix the logic by ignoring the `v100` default in the case.
* | VS15: Add Visual Studio 15 generatorBrad King2016-09-071-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Call the generator "Visual Studio 15" without any year because the preview version of VS 15 does not provide a year in the product name. Copy cmGlobalVisualStudio14Generator to cmGlobalVisualStudio15Generator and update version numbers accordingly. Add the VS15 enumeration value. Note that we do not need to add a MSVC15 variable or v150 toolset because Visual Studio 15 comes with an updated version of the v140 toolset and remains ABI-compatible. Teach tests VSExternalInclude, RunCMake.GeneratorPlatform, and RunCMake.GeneratorToolset to treat VS 15 as they do VS 10-14. Closes: #16143
* | VS: Verify that MSBuild.exe and devenv.com exist before using themBrad King2016-09-061-4/+10
| |
* | fix a load of include-what-you-use violationsDaniel Pfeifer2016-09-031-0/+1
|/
* VS: Explicitly default to v100 toolset in Visual Studio 2010Benjamin Ballet2016-07-211-0/+1
| | | | | Otherwise `CMAKE_VS_PLATFORM_TOOLSET` is not set even though the `v100` toolset is chosen.
* CMake: Report whether generators support platformsTobias Hunger2016-07-141-0/+1
|
* cmGlobalGeneratorFactory: Use CM_OVERRIDE for all derived classesTobias Hunger2016-07-141-5/+5
|
* Revise C++ coding style using clang-formatKitware Robot2016-05-161-219/+153
| | | | | | | | | | | | | Run the `Utilities/Scripts/clang-format.bash` script to update all our C++ code to a new style defined by `.clang-format`. Use `clang-format` version 3.8. * If you reached this commit for a line in `git blame`, re-run the blame operation starting at the parent of this commit to see older history for the content. * See the parent commit for instructions to rebase a change across this style transition commit.
* Remove `//------...` horizontal separator commentsBrad King2016-05-091-28/+0
| | | | | | | | | | | | | | | | | | | | | | | | Modern editors provide plenty of ways to visually separate functions. Drop the explicit comments that previously served this purpose. Use the following command to automate the change: $ git ls-files -z -- \ "*.c" "*.cc" "*.cpp" "*.cxx" "*.h" "*.hh" "*.hpp" "*.hxx" | egrep -z -v "^Source/cmCommandArgumentLexer\." | egrep -z -v "^Source/cmCommandArgumentParser(\.y|\.cxx|Tokens\.h)" | egrep -z -v "^Source/cmDependsJavaLexer\." | egrep -z -v "^Source/cmDependsJavaParser(\.y|\.cxx|Tokens\.h)" | egrep -z -v "^Source/cmExprLexer\." | egrep -z -v "^Source/cmExprParser(\.y|\.cxx|Tokens\.h)" | egrep -z -v "^Source/cmFortranLexer\." | egrep -z -v "^Source/cmFortranParser(\.y|\.cxx|Tokens\.h)" | egrep -z -v "^Source/cmListFileLexer\." | egrep -z -v "^Source/cm_sha2" | egrep -z -v "^Source/(kwsys|CursesDialog/form)/" | egrep -z -v "^Utilities/(KW|cm).*/" | xargs -0 sed -i '/^\(\/\/---*\|\/\*---*\*\/\)$/ {d;}' This avoids modifying third-party sources and generated sources.
* Isolate formatted streaming blocks with clang-format off/onBrad King2016-05-061-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The clang-format tool can do a good job formatting most code, but well-organized streaming blocks are best left manually formatted. Find blocks of the form os << "...\n" "...\n" ; using the command $ git ls-files -z -- Source | egrep -v -z '^Source/kwsys/' | xargs -0 pcregrep -M --color=always -B 1 -A 1 -n \ '<<[^\n]*\n(^ *("[^\n]*("|<<|;)$|;)\n){2,}' Find blocks of the form os << "...\n" << "...\n" << "...\n"; using the command $ git ls-files -z -- Source | egrep -v -z '^Source/kwsys/' | xargs -0 pcregrep -M --color=always -B 1 -A 1 -n \ '<<[^\n]*\n(^ *<<[^\n]*(\\n"|<<|;)$\n){2,}' Surround such blocks with the pair /* clang-format off */ ... /* clang-format on */ in order to protect them from update by clang-format. Use the C-style `/*...*/` comments instead of C++-style `//...` comments in order to prevent them from ever being swallowed by re-formatting of surrounding comments.
* Format include directive blocks and ordering with clang-formatBrad King2016-04-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sort include directives within each block (separated by a blank line) in lexicographic order (except to prioritize `sys/types.h` first). First run `clang-format` with the config file: --- SortIncludes: false ... Commit the result temporarily. Then run `clang-format` again with: --- SortIncludes: true IncludeCategories: - Regex: 'sys/types.h' Priority: -1 ... Commit the result temporarily. Start a new branch and cherry-pick the second commit. Manually resolve conflicts to preserve indentation of re-ordered includes. This cleans up the include ordering without changing any other style. Use the following command to run `clang-format`: $ git ls-files -z -- \ '*.c' '*.cc' '*.cpp' '*.cxx' '*.h' '*.hh' '*.hpp' '*.hxx' | egrep -z -v '(Lexer|Parser|ParserHelper)\.' | egrep -z -v '^Source/cm_sha2' | egrep -z -v '^Source/(kwsys|CursesDialog/form)/' | egrep -z -v '^Utilities/(KW|cm).*/' | egrep -z -v '^Tests/Module/GenerateExportHeader' | egrep -z -v '^Tests/RunCMake/CommandLine/cmake_depends/test_UTF-16LE.h' | xargs -0 clang-format -i This selects source files that do not come from a third-party. Inspired-by: Daniel Pfeifer <daniel@pfeifer-mail.de>
* Source: Stabilize include orderBrad King2016-04-291-0/+2
| | | | | Each source file has a logical first include file. Include it in an isolated block so that tools that sort includes do not move them.
* VS: Ignore USE_FOLDER property on VS versions that do not support itBrad King2016-04-261-6/+0
| | | | | Solution folders are supported on VS 8 and above in the full versions and on VS 11 and above in the express versions.
* cmake-gui: Add option to specify generator toolsetRobert Dailey2015-11-171-0/+2
| | | | | | | | | | The -T parameter to CMake may now be specified through cmake-gui via a new text field in the first-time configure wizard (below the generator chooser). The generator factories specify whether or not they support toolsets. This information is propagated to the Qt code and used to determine if the selected generator should also display the optional Toolset widgets.
* VS10: Port to cmGeneratorTarget.Stephen Kelly2015-10-241-5/+7
|
* VisualStudio10: Initialize the LongestSource at generate time.Stephen Kelly2015-10-051-11/+1
| | | | There is no need to initialize it at compute time.
* VS: Add hook to initialize Windows platform settingsGilles Khouzam2015-10-021-3/+16
| | | | | Give VS 10+ generators a chance to choose Windows platform settings just as they already can for WindowsCE, WindowsStore, and WindowsPhone.
* cmLocalGenerator: Create from already-constructed cmMakefile.Stephen Kelly2015-08-281-2/+2
| | | | Don't manage the lifetime of the cmMakefile with cmLocalGenerator.
* cmLocalGenerator: Remove Parent pointer.Stephen Kelly2015-08-281-4/+3
|
* cmGlobalGenerator: Virtualize the Compute step and override it.Stephen Kelly2015-07-301-1/+10
|
* cmLocalGenerator: Require a valid cmState::Snapshot in the ctor.Stephen Kelly2015-05-271-2/+3
| | | | | | | | | | | Refactor the local generator creation API to accept a cmState::Snapshot. Adjust MakeLocalGenerator to use the 'current' snapshot in cases where there is no parent. Create the snapshot for subdirectories in cmMakefile::AddSubdirectory. This means that snapshots are now created at the point of extending the tree, as appropriate, and independently of the cmLocalGenerator and cmMakefile they represent the state for.
* cmGlobalGenerator: Require a cmake instance in ctor.Stephen Kelly2015-05-271-10/+7
| | | | It is required anyway, so this makes it explicit.
* VS: Move version information to global generator.Stephen Kelly2015-05-191-2/+2
|
* cmLocalGenerator: Require a global generator in the constructor.Stephen Kelly2015-05-141-5/+2
| | | | Port generator factory methods to pass it.
* cmLocalGenerator: Require a parent in the constructor.Stephen Kelly2015-04-281-2/+4
| | | | | | | Pass the parent though cmGlobalGenerator::CreateLocalGenerator. This will make it easy to initialize state scopes independent of cmMakefile.
generated by cgit v0.12 at 2024-12-29 06:49:20 (GMT)