summaryrefslogtreecommitdiffstats
path: root/Source/cmGlobalVisualStudio14Generator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* 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'
* cmGlobalVisualStudio14Generator: notify when the SDK version doesn't matchBen Boeckel2017-07-131-0/+7
| | | | | | | | When requesting an SDK version which is not suitable (e.g., missing `windows.h`), CMake will use the next-best SDK version. Output a message when CMake chooses something different than the requested SDK version. See #16895.
* VS: Split link flag table between v140 and v141 toolsetsIan Hojnicki2017-06-281-2/+2
|
* VS: Add an environment variable for the Windows 10 kits directoryBrad King2017-04-121-0/+8
| | | | | | | | | | | | | | | | | Define a `CMAKE_WINDOWS_KITS_10_DIR` environment variable to allow users to tell CMake about a custom Windows 10 SDK directory. We choose to make this an environment variable rather than a CMake variable or cache entry because: * Using a custom directory also requires custom external MSBuild configuration. Therefore users are already configuring a custom environment. * The custom directory must be set consistently in all parts of a build including nested projects. An environment variable avoids requiring users to thread the setting into nested builds. Fixes: #16743
* VS: Refactor Win 10 Kits root detection to support multiple rootsBrad King2017-04-121-13/+25
|
* cmAlgorithms: add cmEraseIf functionDaniel Pfeifer2017-02-101-2/+1
|
* VS: Add flag tables for C#Michael Stürmer2016-12-011-0/+2
| | | | | | | 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-0/+1
|
* VS: Move toolset flag table lookup to global generatorDon Olmstead2016-10-251-0/+10
| | | | | Move `Get*FlagTable` methods to the global generator and have each VS generator version pre-populate its default flag table.
* 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.
* 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-113/+84
| | | | | | | | | | | | | 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-11/+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.
* 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/+1
| | | | | 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.
* Merge topic 'vs-win10-sdk'Brad King2016-01-251-4/+5
|\ | | | | | | | | d7e863c1 VS: Do not fail on Windows 10 with VS 2015 if no SDK is available (#15929)
| * VS: Do not fail on Windows 10 with VS 2015 if no SDK is available (#15929)Brad King2016-01-211-4/+5
| | | | | | | | | | | | | | | | | | | | | | Since commit v3.4.0-rc1~5^2~1 (VS: Add support for selecting the Windows 10 SDK, 2015-09-30) the VS 2015 generator requires a Windows 10 SDK to be available when CMAKE_SYSTEM_VERSION specifies Windows 10 (e.g. when building on a Windows 10 host). Howewver, it is possible to install VS 2015 without any Windows 10 SDK. Instead of failing with an error message about the lack of a Windows 10 SDK, simply tolerate this case and use the default Windows 8.1 SDK. Since building for Windows Store still requires the SDK, retain the diagnostic in that case.
* | Merge topic 'vs-win10-sdk'Brad King2016-01-121-17/+25
|\ \ | |/ | | | | | | | | | | a57caf7e VS: Fix Windows 10 SDK version selection (#15831) ad594de8 cmSystemTools: Add VersionCompareEqual helper c173e37f VS: Do not select a partial Windows 10 SDK folder (#15831)
| * VS: Fix Windows 10 SDK version selection (#15831)Brad King2016-01-111-17/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit v3.4.0-rc1~5^2~1 (VS: Add support for selecting the Windows 10 SDK, 2015-09-30) we added Windows 10 SDK selection choosing the most recent SDK that is not newer than the target version. This is backward because it should be up to the application code to not use APIs newer than the target version. It is up to the build system to provide a SDK that has at least the APIs expected to be available for the target version. Furthermore, since the default target version is the host version of Windows, the old approach breaks when the only SDK available is for a newer version of Windows. Fix this by always selecting a Windows 10 SDK if one exists. Use the SDK for the exact version if is available. Otherwise use the latest version of the SDK available because that will have at least the APIs expected for the target version.
| * VS: Do not select a partial Windows 10 SDK folder (#15831)Brad King2016-01-081-0/+16
| | | | | | | | | | Skip SDK candidate folders that do not contain <um/windows.h> as they are not full SDKs.
* | 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.
* VS: Select Windows 10 Store SDK and toolset for VS 2015Gilles Khouzam2015-10-021-0/+63
|
* VS: Select latest Windows 10 SDK if no specific version was requestedGilles Khouzam2015-10-021-5/+14
| | | | | If CMAKE_SYSTEM_VERSION is just "10.0" then use the latest SDK available since no particular version was requested.
* VS: Add support for selecting the Windows 10 SDK (#15670)Gilles Khouzam2015-10-021-0/+80
| | | | | | | | | Teach the VS 2015 generator to produce a WindowsTargetPlatformVersion value. Use the CMAKE_SYSTEM_VERSION to specify the version and if not set choose a default based on available SDKs. Activate this behavior when targeting Windows 10. Co-Author: Brad King <brad.king@kitware.com>
* VS: Find Desktop SDK for current VS version (#15662)Gilles Khouzam2015-09-021-0/+13
| | | | | | Determine the Desktop SDK for Windows Phone and Windows Store from the generator instead of the version of the targeted app. This allows to build a Windows Phone 8.1 app on VS 2015 for example.
* cmGlobalGenerator: Require a cmake instance in ctor.Stephen Kelly2015-05-271-10/+7
| | | | It is required anyway, so this makes it explicit.
* VS: Remove obsolete methods.Stephen Kelly2015-05-191-7/+0
| | | | Base class implementations for these are identical.
* 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.
* 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
|
* VS: Rename VS 14 generator to 'Visual Studio 14 2015'Brad King2014-11-141-10/+30
| | | | | | Now that we know the year component of this VS version we can add it to the generator name. For convenience, map the name without the year to the name with the year.
* VS: Delay getting platform name in local generatorBrad King2014-07-171-1/+0
| | | | | | Ask the global generator during generation instead of trying to store it up front. Later the global generator may not know the platform name when it is creating the local generator.
* VS: Refactor CMAKE_FORCE_*64 platform definitionsBrad King2014-07-171-7/+5
| | | | | | | Remove the general infrastructure for these additional platform definitions and hard-code the only two special cases that used it. They are only for historical reasons so no new such cases should be added.
* VS14: Add Visual Studio 14 generator (#14982)Brad King2014-06-251-0/+116
Call the generator "Visual Studio 14" without any year because this version of VS does not provide a year in the product name. Copy cmGlobalVisualStudio12Generator to cmGlobalVisualStudio14Generator and update version numbers accordingly. Add the VS14 enumeration value. Teach the platform module Windows-MSVC to set MSVC14 and document the variable. Teach module InstallRequiredSystemLibraries to look for the VS 14 runtime libraries. Teach tests CheckCompilerRelatedVariables, VSExternalInclude, and RunCMake.GeneratorToolset to treat VS 14 as they do VS 10, 11, and 12. Co-Author: Pawel Stopinski <diokhan@go2.pl>
generated by cgit v0.12 at 2024-09-03 09:10:26 (GMT)