summaryrefslogtreecommitdiffstats
path: root/Source/cmGlobalVisualStudio10Generator.h
Commit message (Collapse)AuthorAgeFilesLines
* VS: Use 'override' keyword for overridden methods in generator classesVitaly Stakhovsky2017-12-161-21/+23
| | | | The corresponding 'virtual' removed.
* VS: Emit "utf-8" encoding as lowercase in .vcxproj headersVitaly Stakhovsky2017-12-141-0/+1
| | | | Match the XML preamble generated by VS 2010 and later.
* Use C++11 override instead of CM_OVERRIDEBrad King2017-09-151-1/+1
| | | | | | | | 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'
* VS: Fix GenerateDebugInformation values for v140 and v141 toolsetsBrad King2017-06-281-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Add placeholder CUDA flag tablesBrad King2017-03-101-0/+4
| | | | | | | 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: Provide an option to specify CUDA toolset versionBrad King2017-03-101-0/+5
| | | | | | | | 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/+3
| | | | | | 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-1/+5
| | | | | | | | | | | | | | | | | 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/+2
| | | | Fixes: #16469
* 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.
* VS: Choose flag map based on the toolset nameDon Olmstead2016-10-251-0/+2
| | | | | | | | | 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/+11
| | | | | 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-0/+1
|
* cmGlobalGenerator: Allow FindMakeProgram to failBrad King2016-10-201-1/+1
| | | | | 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-0/+5
| | | | | | | | | | 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.
* Revise C++ coding style using clang-formatKitware Robot2016-05-161-26/+23
| | | | | | | | | | | | | 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.
* VS: Ignore USE_FOLDER property on VS versions that do not support itBrad King2016-04-261-2/+0
| | | | | Solution folders are supported on VS 8 and above in the full versions and on VS 11 and above in the express versions.
* VS: Detect VS 8 and 9 Express editionsBrad King2016-04-261-4/+0
|
* VS10: Port to cmGeneratorTarget.Stephen Kelly2015-10-241-2/+2
|
* VisualStudio10: Initialize the LongestSource at generate time.Stephen Kelly2015-10-051-2/+0
| | | | There is no need to initialize it at compute time.
* VS: Add support for selecting the Windows 10 SDK (#15670)Gilles Khouzam2015-10-021-0/+5
| | | | | | | | | 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: Add hook to initialize Windows platform settingsGilles Khouzam2015-10-021-0/+1
| | | | | 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-1/+1
| | | | Don't manage the lifetime of the cmMakefile with cmLocalGenerator.
* cmLocalGenerator: Remove Parent pointer.Stephen Kelly2015-08-281-2/+1
|
* cmGlobalGenerator: Virtualize the Compute step and override it.Stephen Kelly2015-07-301-0/+2
|
* cmLocalGenerator: Require a valid cmState::Snapshot in the ctor.Stephen Kelly2015-05-271-1/+2
| | | | | | | | | | | 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-1/+1
| | | | It is required anyway, so this makes it explicit.
* cmLocalGenerator: Require a parent in the constructor.Stephen Kelly2015-04-281-1/+1
| | | | | | | Pass the parent though cmGlobalGenerator::CreateLocalGenerator. This will make it easy to initialize state scopes independent of cmMakefile.
* VS: Drop reload macros for VS >= 10 (#11258,#14680)Brad King2015-04-151-12/+3
| | | | | | | | 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: Teach --build to honor CMAKE_VERBOSE_MAKEFILE for NinjaGregor Jasny2015-02-261-1/+1
| | | | | | | | | 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>
* Merge topic 'vs-check-phone-store-tools'Brad King2014-11-181-2/+3
|\ | | | | | | | | | | 689cd0d4 VS: Do not produce WinMD file for OBJECT libraries (#15228) b20a32ac VS: Improve error messages when compiler is not detected (#15228)
| * VS: Improve error messages when compiler is not detected (#15228)Gilles Khouzam2014-11-141-2/+3
| | | | | | | | | | | | | | | | 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.
* | Fix some spelling errors in commentsGeoff Viola2014-10-131-1/+1
|/
* VS: Generate Nsight Tegra project revision numberBrad King2014-09-301-0/+1
| | | | | | 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/+6
| | | | | | | 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-0/+7
| | | | | | | | 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-0/+1
| | | | | | | | | 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.
* cmGlobalVisualStudio10Generator: Re-order some methodsBrad King2014-09-051-1/+1
| | | | | Order SetSystemName and SetGeneratorToolset method declarations and definitions as they are called.
* cmGlobalGenerator: Call SetGeneratorToolset even for empty toolsetBrad King2014-09-051-1/+0
| | | | | | Move handling of an empty toolset name into the implementation of the method. This simplifies the VS 10 implementation of default toolset selection because it has one code path that is always called.
* VS: Move internal MasmEnabled member up to VS 7 generatorBrad King2014-08-201-4/+0
| | | | | | | | Move the member from cmGlobalVisualStudio10Generator to cmGlobalVisualStudio7Generator to make it useful for earlier versions of VS. Set the member to true only starting with cmGlobalVisualStudio8Generator since we will not implement MASM support for versions less than VS 8.
* VS: Select WindowsPhone and WindowsStore default toolsetsBrad King2014-07-311-0/+4
| | | | | | | | Teach the VS >= 10 generators to recognize these system names and select the appropriate default toolset for the system version. Report an error when the version is not known to be supported by VS. Inspired-by: Gilles Khouzam <gillesk@microsoft.com>
* VS: Save WindowsPhone and WindowsStore system internallyBrad King2014-07-311-0/+10
| | | | | | | | Add boolean members to the VS >= 10 global generator to save whether CMAKE_SYSTEM_NAME is WindowsPhone or WindowsStore without having to repeat a string comparison. Inspired-by: Gilles Khouzam <gillesk@microsoft.com>
* VS: Add internal API to get system name and versionBrad King2014-07-311-0/+6
| | | | | Add cmGlobalVisualStudio10Generator::GetSystemName and GetSystemVersion methods to access the corresponding members publicly.
* VS: Add a hook to adapt to SystemName and SystemVersionBrad King2014-07-281-0/+1
| | | | | | | Add a virtual cmGlobalVisualStudio10Generator::InitializeSystem method called from SetSystemName once the SystemName and SystemVersion members have been populated. This will give VS version-specific generators a chance to recognize and adapt to the target system.
* VS: Save system name and version in global generator membersBrad King2014-07-281-0/+2
| | | | | Add to cmGlobalVisualStudio10Generator members for SystemName and SystemVersion and populate them in SetSystemName.
* cmGlobalGenerator: Create a non-virtual 'DoGenerate' methodBrad King2014-07-221-2/+2
| | | | | | | Make the virtual 'Generate' method protected. Make 'DoGenerate' the main entry point to generation. This gives cmGlobalGenerator a chance to do some early operations before the individual generator-specific implementations take over.
* VS: Delay platform definitions until system name is knownBrad King2014-07-171-2/+1
| | | | | | | Move the definition of CMAKE_VS_PLATFORM_NAME and other variables that are not needed by CMakeDetermineSystem out of the AddPlatformDefinitions method and into a SetSystemName method. The latter may later use CMAKE_SYSTEM_NAME to decide what platform-specific definitions to add.
* VS: Refactor CMAKE_FORCE_*64 platform definitionsBrad King2014-07-171-2/+1
| | | | | | | 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.
generated by cgit v0.12 at 2024-11-11 21:20:21 (GMT)