summaryrefslogtreecommitdiffstats
path: root/Source/cmGlobalVisualStudio7Generator.h
Commit message (Collapse)AuthorAgeFilesLines
* VS: Pass whole target to WriteProjectConfigurationsBeeble2017-04-051-2/+2
|
* VS: Add support for ASM_NASM languageEvgeny Fimochkin2017-02-071-0/+2
| | | | Fixes: #16469
* 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.
* cmState: Move TargetType enum to separate namespaceStephen Kelly2016-10-191-1/+1
|
* 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/+6
|
* Revise C++ coding style using clang-formatKitware Robot2016-05-161-38/+31
| | | | | | | | | | | | | 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.
* 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.
* Drop Visual Studio 7 generator for VS .NET 2002Brad King2016-03-111-19/+7
| | | | This generator has been deprecated since CMake 3.3. Remove it.
* cmake-gui: Add option to specify generator toolsetRobert Dailey2015-11-171-0/+6
| | | | | | | | | | 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.
* VS7: Port remaining interface to cmGeneratorTargetStephen Kelly2015-10-271-2/+2
|
* VS: Port interface to cmGeneratorTargetStephen Kelly2015-10-241-1/+2
|
* VS: Port WriteUtilityDepends to cmGeneratorTargetStephen Kelly2015-10-241-1/+1
|
* VS: Port ProjectDepends to cmGeneratorTarget.Stephen Kelly2015-10-241-1/+1
|
* VS: Port WriteProject to cmGeneratorTargetStephen Kelly2015-10-241-1/+1
|
* cmState: Move TargetType enum from cmTarget.Stephen Kelly2015-10-141-1/+1
| | | | | | | Mostly automated: values=( "EXECUTABLE" "STATIC_LIBRARY" "SHARED_LIBRARY" "MODULE_LIBRARY" "OBJECT_LIBRARY" "UTILITY" "GLOBAL_TARGET" "INTERFACE_LIBRARY" "UNKNOWN_LIBRARY" "TargetType") for i in "${values[@]}"; do git grep -l cmTarget::$i | xargs sed -i "s|cmTarget::$i|cmState::$i|g"; done
* 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
|
* VS: Compute project GUIDs deterministicallyBrad King2015-06-041-3/+2
| | | | | | | | | Compute deterministic GUIDs that are unique to the build tree by hashing the path to the build tree with the GUID logical name. Avoid storing them in the cache, but honor any found there. This will allow project GUIDs to be reproduced in a fresh build tree so long as its path is the same as the original, which may be useful for incremental builds.
* 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/+2
| | | | It is required anyway, so this makes it explicit.
* VS: Do not accumulate configurations globally (#15577)Brad King2015-05-211-9/+4
| | | | | | | | | | | Drop the VS >= 7 generator's global Configurations member and instead lookup configurations using cmMakefile::GetConfigurations where needed. This avoids accumulating all CMAKE_CONFIGURATION_TYPES values ever encountered by a project() or enable_language() command and allows the final value to be used in each directory. We don't officially support per-directory CMAKE_CONFIGURATION_TYPES values but we certainly should not generate configurations not in the final value in the top level directory.
* VS: Simplify setting of flag table.Stephen Kelly2015-05-191-1/+2
|
* 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.
* 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>
* VS: Use $(ConfigurationName) as CMAKE_CFG_INTDIR in VS 7, 8, 9Brad King2015-02-161-1/+2
| | | | | | | | | This will allow us to use a value other than just the config name for the project OutputDirectory setting used for $(OutDir). Also use $(ConfigurationName) instead of $(OutDir) for the link directory configuration suffix since that is a hard-coded instance of a use case for CMAKE_CFG_INTDIR.
* Fix some spelling errors in commentsGeoff Viola2014-10-131-1/+1
|
* VS: Implement CMAKE_GENERATOR_PLATFORM for VS >= 8Brad King2014-09-051-0/+3
| | | | | | | | | 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-2/+2
| | | | | | 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.
* VS: Move internal MasmEnabled member up to VS 7 generatorBrad King2014-08-201-0/+4
| | | | | | | | 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.
* cmGlobalGenerator: Create a non-virtual 'DoGenerate' methodBrad King2014-07-221-7/+1
| | | | | | | 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-1/+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: Remove unused parameter of WriteTargetConfigurationsBrad King2014-06-131-1/+0
| | | | | The cmGlobalVisualStudio7Generator::WriteTargetConfigurations 'root' parameter is no longer used, so remove it.
* VS: Fix subproject .sln dependencies on custom targetsBrad King2014-06-121-3/+5
| | | | | | | | | | | | | | | | | | | | | | Each project listed in a .sln must be marked (or not) as part of the "default build" for each configuration. For targets created by the add_custom_target() command we add them to the default build if they are not excluded in some way or if another target depends on them. In the top-level .sln, a custom target is excluded if it is not created with the ALL option to add_custom_target. In subdirectory .sln files, a target may also be excluded if it is not within the directory and is brought into the solution only due to a dependency from another target in the solution. Fix the "IsPartOfDefaultBuild" and "IsDependedOn" methods to check every target to be included in the .sln for a dependency on the custom target. Otherwise transitive dependencies through targets not in the current subdirectory will not be considered. Extend the SubProject test with a custom target to cover this case. Reported-by: William Deurwaarder <William.Deurwaarder@tomtom.com> Reported-by: Dirk Steenpass <dirk.steenpass@gmail.com>
* VS: Move VS-only API out of cmGlobalGeneratorBrad King2014-06-121-0/+1
| | | | | Move the IsDependedOn method to cmGlobalVisualStudio7Generator since that is the only caller.
* Encoding: If configured, write Visual Studio project files as UTF-8.Clinton Stimpson2014-03-141-0/+3
|
* stringapi: Use strings for program pathsBen Boeckel2014-03-081-1/+1
|
* stringapi: Use strings for generator namesBen Boeckel2014-03-081-5/+5
|
* stringapi: Use strings for directoriesBen Boeckel2014-03-081-1/+1
|
* stringapi: Miscellaneous char* parametersBen Boeckel2014-03-081-3/+3
|
* stringapi: Pass configuration names as stringsBen Boeckel2014-03-081-2/+2
|
* strings: Remove cmStdString referencesBen Boeckel2014-03-081-2/+2
| | | | | | | | | | | Casts from std::string -> cmStdString were high on the list of things taking up time. Avoid such implicit casts across function calls by just using std::string everywhere. The comment that the symbol name is too long is no longer relevant since modern debuggers alias the templates anyways and the size is a non-issue since the underlying methods are generated since it's inherited.
* stringapi: Use strings for VS project namesBen Boeckel2014-03-081-7/+7
|
* stringapi: Use strings in target nameBen Boeckel2014-03-081-1/+1
|
* VS: Teach include_external_msproject about non-C++ projects (#14661)David Golub2013-12-201-0/+2
| | | | | | Teach CMake to guess the project type guid based on the project file extension. This allows non-C++ projects like *.vbproj or *.csproj to be included.
* Constify handling of target dependencies.Stephen Kelly2013-12-111-4/+6
|
* VS: Add CMAKE_VS_(DEVENV|MSBUILD|MSDEV)_COMMAND variablesBrad King2013-12-041-0/+2
| | | | | | | | Since commit 5f5c92b9 (VS: Add internal APIs to find MSBuild, devenv/VCExpress, and msdev, 2013-11-13) the VS generators have known how to lookup the locations of their build tools directly. Expose this information to CMake language code by defining new variables to hold the paths to these tools.
* VS: Switch to internal CMAKE_MAKE_PROGRAM lookup by generatorsBrad King2013-11-181-0/+1
| | | | | | | | Drop the "Modules/CMakeVS*FindMake.cmake" files. Override the cmGlobalGenerator::FindMakeProgram method for VS generators to use their internal APIs to locate the build tool. Set the CMAKE_MAKE_PROGRAM as a normal variable for use by project code, but do not cache it. This will allow CMake and CTest to select the proper tool at build time.
* VS: Add internal APIs to find MSBuild, devenv/VCExpress, and msdevBrad King2013-11-181-0/+5
| | | | | Teach the VS generators to compute the locations of these tools directly from registry entries. Add internal APIs to get the locations on demand.
* cmGlobalGenerator: Cleanup GenerateBuildCommand APIBrad King2013-11-181-8/+10
| | | | | | | | | All cmGlobalGenerator::GenerateBuildCommand call sites that need to produce a string now generate "cmake --build" commands. The remaining call sites immediately pass the result to cmSystemTools::RunSingleCommand. Avoid the intermediate string and argument parsing by directly producing a vector of strings. Also drop the ignoreErrors argument because no call sites remain that use it.