summaryrefslogtreecommitdiffstats
path: root/Source/cmGlobalVisualStudio10Generator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* cmMakefile: Rename GetCurrent{Output,Binary}Directory.Stephen Kelly2015-04-201-2/+2
| | | | Match names used in CMake code.
* VS: Drop reload macros for VS >= 10 (#11258,#14680)Brad King2015-04-151-33/+0
| | | | | | | | We never implemented them for VS 11 (2012), 12 (2013), or 14 (2015). For VS 10 (2010) the reload macro does not work correctly when run from inside a build launched through the IDE because stopping the build kills the CMake that is driving the reload. Fortunately VS >= 10 know how to reload the whole solution anyway.
* cmake: Show in --help how to select VS target platform (#15422)Brad King2015-04-071-2/+5
| | | | | | | | | * Re-order VS generators from newest to oldest. * Show how to specify a VS generator with a target platform * Increase the option output indentation to avoid extra wrapping with longer generator names.
* Include cmAlgorithms where it is used.Stephen Kelly2015-03-101-0/+1
|
* cmake: Teach --build to honor CMAKE_VERBOSE_MAKEFILE for NinjaGregor Jasny2015-02-261-2/+2
| | | | | | | | | The Ninja build system does not support a in-file verbositiy switch. Instead teach 'cmake --build' to extract the CMAKE_VERBOSE_MAKEFILE setting and pass it as an optional '-v' argument to Ninja. This can serve as a reasonable fallback. Signed-off-by: Gregor Jasny <gjasny@googlemail.com>
* Port all cmOStringStream to std::ostringstream.Stephen Kelly2015-01-111-8/+8
| | | | All compilers hosting CMake support the std class.
* VS: Improve error messages when compiler is not detected (#15228)Gilles Khouzam2014-11-141-0/+18
| | | | | | | | CMake requires both the Desktop SDK and the correct platform SDK (Windows Phone or Windows Store) to be installed when targeting the Windows mobile platforms. Verify that the right platform components are installed and give a more detailed error message when something is wrong.
* VS: Generate Nsight Tegra project revision numberBrad King2014-09-301-0/+6
| | | | | | Nsight Tegra 2.0 will be revision '8'. Generate this revision number and add a NsightTegraUpgradeOnceWithoutPrompt element to tell newer versions not to prompt when upgrading the generated project file.
* VS: Teach VS >= 10 to recognize CMAKE_SYSTEM_NAME 'Android'Brad King2014-09-291-0/+41
| | | | | | | When CMAKE_SYSTEM_NAME is 'Android', check for an installation of 'NVIDIA Nsight Tegra Visual Studio Edition' and generate .vcxproj files for the "Tegra-Android" platform. Also make the installed version available in a CMAKE_VS_NsightTegra_VERSION variable.
* VS: Teach VS >= 10 generator about Windows CEPascal Bach2014-09-151-1/+47
| | | | | | | | When CMAKE_SYSTEM_NAME is 'WindowsCE': * Set the Subsystem and EntryPointSymbol accordingly. * When CMAKE_SYSTEM_VERSION is 8.0 (Windows CE 2013), select the CE800 toolset by default.
* VS: Implement CMAKE_GENERATOR_PLATFORM for VS >= 8Brad King2014-09-051-1/+13
| | | | | | | | | For VS generator names that do not specify the platform name, read CMAKE_GENERATOR_PLATFORM to get it. Extend the RunCMake.GeneratorPlatform test with a case covering use of the x64 platform when the test generator is a Visual Studio generator whose name does not specify a platform.
* VS: Refactor internal default platform name selectionBrad King2014-09-051-1/+1
| | | | | | Rename the 'PlatformName' member to 'DefaultPlatformName' and make sure it is only read through a 'GetPlatformName()' call. This will allow non-default names to be chosen later.
generated by cgit v0.12 at 2024-11-11 19:01:22 (GMT)