summaryrefslogtreecommitdiffstats
path: root/Source/cmGlobalVisualStudio8Generator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* cmComputeTargetDepends: Change API to use cmGeneratorTarget.Stephen Kelly2015-07-011-1/+2
|
* Merge topic 'remove-CMAKE_USE_RELATIVE_PATHS'Brad King2015-06-041-6/+2
|\ | | | | | | | | | | | | | | 6e570f85 cmLocalGenerator: Remove 'optional' parameter from Convert. 3d8c6cd9 cmLocalGenerator: Remove obsolete method. e44e6bcc Port away from obsolete method. 1335992c Remove CMAKE_USE_RELATIVE_PATHS variable.
| * cmLocalGenerator: Remove 'optional' parameter from Convert.Stephen Kelly2015-06-041-6/+2
| | | | | | | | Port callers away from it.
* | VS: Compute project GUIDs deterministicallyBrad King2015-06-041-1/+0
|/ | | | | | | | | 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.
* cmGlobalGenerator: Require a cmake instance in ctor.Stephen Kelly2015-05-271-10/+8
| | | | It is required anyway, so this makes it explicit.
* VS: Do not accumulate configurations globally (#15577)Brad King2015-05-211-5/+7
| | | | | | | | | | | 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.
* Use cmSystemTools::GetCMakeCommand() to get path to cmake internallyBrad King2015-05-201-3/+1
| | | | | This is much simpler than finding a way to lookup "CMAKE_COMMAND" everywhere.
* VS: Remove obsolete methods.Stephen Kelly2015-05-191-10/+0
| | | | Base class implementations for these are identical.
* VS: Move version information to global generator.Stephen Kelly2015-05-191-2/+2
|
* VS: Simplify setting of flag table.Stephen Kelly2015-05-191-1/+1
|
* cmLocalGenerator: Require a global generator in the constructor.Stephen Kelly2015-05-141-2/+1
| | | | 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.
* 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.
* Add an option for explicit BYPRODUCTS of custom commands (#14963)Brad King2014-11-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A common idiom in CMake-based build systems is to have custom commands that generate files not listed explicitly as outputs so that these files do not have to be newer than the inputs. The file modification times of such "byproducts" are updated only when their content changes. Then other build rules can depend on the byproducts explicitly so that their dependents rebuild when the content of the original byproducts really does change. This "undeclared byproduct" approach is necessary for Makefile, VS, and Xcode build tools because if a byproduct were listed as an output of a rule then the rule would always rerun when the input is newer than the byproduct but the byproduct may never be updated. Ninja solves this problem by offering a 'restat' feature to check whether an output was really modified after running a rule and tracking the fact that it is up to date separately from its timestamp. However, Ninja also stats all dependencies up front and will only restat files that are listed as outputs of rules with the 'restat' option enabled. Therefore an undeclared byproduct that does not exist at the start of the build will be considered missing and the build will fail even if other dependencies would cause the byproduct to be available before its dependents build. CMake works around this limitation by adding 'phony' build rules for custom command dependencies in the build tree that do not have any explicit specification of what produces them. This is not optimal because it prevents Ninja from reporting an error when an input to a rule really is missing. A better approach is to allow projects to explicitly specify the byproducts of their custom commands so that no phony rules are needed for them. In order to work with the non-Ninja generators, the byproducts must be known separately from the outputs. Add a new "BYPRODUCTS" option to the add_custom_command and add_custom_target commands to specify byproducts explicitly. Teach the Ninja generator to specify byproducts as outputs of the custom commands. In the case of POST_BUILD, PRE_LINK, and PRE_BUILD events on targets that link, the byproducts must be specified as outputs of the link rule that runs the commands. Activate 'restat' for such rules so that Ninja knows it needs to check the byproducts, but not for link rules that have no byproducts.
* VS: Implement CMAKE_GENERATOR_PLATFORM for VS >= 8Brad King2014-09-051-0/+15
| | | | | | | | | 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: Move internal MasmEnabled member up to VS 7 generatorBrad King2014-08-201-0/+8
| | | | | | | | 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: Refactor logic deciding to add "Deploy" to the .sln fileGilles Khouzam2014-07-311-3/+10
| | | | | Move the condition to a "NeedsDeploy" virtual method that can be overridden by more recent VS generators.
* 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: Delay platform definitions until system name is knownBrad King2014-07-171-2/+9
| | | | | | | 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-10/+4
| | | | | | | 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.
* cmGlobalGenerator: Store targets in hash mapsBen Boeckel2014-05-071-1/+1
|
* cmTarget: Use string API to add sources to cmTarget objects.Stephen Kelly2014-03-311-1/+2
| | | | | Continue to call GetOrCreateSource where necessary to create cmSourceFile objects which have the GENERATED attribute set.
* stringapi: Use strings for dependency informationBen Boeckel2014-03-081-1/+1
|
* stringapi: Use strings for generator namesBen Boeckel2014-03-081-12/+17
|
* 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.
* cmTarget: Remove the project argument to FindTargetBen Boeckel2014-03-081-1/+1
| | | | All callers passed 0 in, so just remove the branch.
* stringapi: Use strings for VS project namesBen Boeckel2014-03-081-2/+2
|
* stringapi: Use strings in target nameBen Boeckel2014-03-081-1/+1
|
* Constify handling of target dependencies.Stephen Kelly2013-12-111-1/+1
|
* INTERFACE_LIBRARY: Avoid codepaths which set unneeded properties.Stephen Kelly2013-11-251-1/+2
| | | | | | | | | | | | | As an INTERFACE_LIBRARY has no direct link dependencies, we can short-circuit in cmGeneratorExpressionEvaluator and in cmGlobalGenerator::CheckLocalGenerators. As they do not generate any output directly, any generate- or install- related code acn also be short-circuited. Many of the local generators already do this. Because only INTERFACE related properties make sense on INTERFACE_LIBRARY targets, avoid setting other properties, for example via defaults.
* VS: Switch to internal CMAKE_MAKE_PROGRAM lookup by generatorsBrad King2013-11-181-1/+0
| | | | | | | | 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/+20
| | | | | Teach the VS generators to compute the locations of these tools directly from registry entries. Add internal APIs to get the locations on demand.
* Drop the 'Full' field from cmDocumentationEntryBrad King2013-10-161-6/+0
| | | | | We need only 'Brief' for usage documentation. We no longer have builtin 'Full' documentation, which is now in Help/*/*.rst files.
* Merge topic 'INTERFACE_LIBRARY-target-type'Brad King2013-10-081-0/+4
|\ | | | | | | | | | | | | ce0c303 install: Teach EXPORT option to handle INTERFACE_LIBRARY targets 435c912 export: Add support for INTERFACE_LIBRARY targets fe73226 Add the INTERFACE_LIBRARY target type.
| * Add the INTERFACE_LIBRARY target type.Stephen Kelly2013-10-071-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This target type only contains INTERFACE_* properties, so it can be used as a structural node. The target-specific commands enforce that they may only be used with the INTERFACE keyword when used with INTERFACE_LIBRARY targets. The old-style target properties matching LINK_INTERFACE_LIBRARIES_<CONFIG> are always ignored for this target type. The name of the INTERFACE_LIBRARY must match a validity generator expression. The validity is similar to that of an ALIAS target, but with the additional restriction that it may not contain double colons. Double colons will carry the meaning of IMPORTED or ALIAS targets in CMake 2.8.13. An ALIAS target may be created for an INTERFACE library. At this point it can not be exported and does not appear in the buildsystem and project files are not created for them. That may be added as a feature in a later commit. The generators need some changes to handle the INTERFACE_LIBRARY targets returned by cmComputeLinkInterface::GetItems. The Ninja generator does not use that API, so it doesn't require changes related to that.
* | VS: Fix CMAKE_SUPPRESS_REGENERATION bad ZERO_CHECK dependency (#14378)Brad King2013-08-281-10/+13
|/ | | | | | | When CMAKE_SUPPRESS_REGENERATION tells us not to create the ZERO_CHECK target we should not add dependencies on it from other targets either. Reviewed-by: Mateusz Loskot <mateusz@loskot.net>
* VS: Replace ArchitectureId with PlatformNamePatrick Gansterer2013-08-051-7/+4
| | | | | | | | Since we do not need the information about the target architecture we can use the PlatformName only to specify the this information. This also removes setting of the MSVC_*_ARCHITECTURE_ID variable which is not required, because this variable gets set by the compiler detection code in CMAKE_DETERMINE_COMPILER_ID_CHECK().
* VS: Set CMAKE_VS_PLATFORM_NAME for VS7 and VS71 tooPatrick Gansterer2013-08-051-15/+0
| | | | | Move the code which sets CMAKE_VS_PLATFORM_NAME from cmGlobalVisualStudio8Generator to cmGlobalVisualStudio7Generator.
* VS: Added "Deploy" at project configuration for WindowsCE targetsPatrick Gansterer2012-11-271-1/+10
|
* VS: Make DetermineCompilerId working with WinCE tooPatrick Gansterer2012-11-271-0/+6
| | | | | | Add a dummy mainCRTStartup() function, since the linker searches for it instead of main() and set the CMAKE_SYSTEM_* variables depending on the MSVC_C_ARCHITECTURE_ID and CMAKE_VS_WINCE_VERSION variables.
* VS: Allow setting the name of the target platformPatrick Gansterer2012-11-271-0/+5
| | | | | Since the name for a target platform is independent of its cpu architecture an additional option is required to set it correctly.
* VS: Add parser for WCE.VCPlatform.config to read WinCE platformsPatrick Gansterer2012-11-271-10/+45
| | | | | | Parse the WCE.VCPlatform.config file, which contains the installed WindowsCE SDKs in XML format, and add possibility to generate Visual Studio generators for them.
* VS: Change variable type of ArchitectureId from const char* to stringPatrick Gansterer2012-11-261-2/+2
|
* VS: Add CMAKE_VS_PLATFORM_NAME definition to cmMakefilePatrick Gansterer2012-11-261-0/+7
| | | | | | When adding more platforms to the Visual Studio generators a simple regular expressing can not handle all cases anymore. This new define holds the name of the Visual Studio target platform.
* Merge topic 'generator-factory'Brad King2012-11-201-3/+66
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | 75ebebc VS: Remove platform specific generator files 8b62080 VS: Remove EnableLanguage from platform-specific generators 5bdf011 VS: Remove GetPlatformName from platform-specific generators 8d42ab4 VS: Fix ArchitectureId of Visual Studio 10 IA64 generator 6f439b3 VS: Remove AddPlatformDefinitions from platform-specific generators 5170a88 Make cmGlobalGenerator::GetDocumentation() a static function 04ff866 Allow a GeneratorFactory handling of more than one generator 984ebc3 Search generator in cmake::ExtraGenerators before in cmake::Generators 30a6950 Add cmGlobalGeneratorFactory::GetGenerators() e8f8414 Introduce the abstract class cmGlobalGeneratorFactory
| * VS: Remove platform specific generator filesPatrick Gansterer2012-11-191-1/+54
| | | | | | | | Move the whole logic into the base class and the factory.
| * VS: Remove GetPlatformName from platform-specific generatorsPatrick Gansterer2012-11-191-0/+10
| | | | | | | | | | Use the existing ArchitectureId to generate the PlatformName to reduce duplicated information in the classes.
| * Make cmGlobalGenerator::GetDocumentation() a static functionPatrick Gansterer2012-11-191-2/+2
| | | | | | | | | | Making the function static allows us to call it directly, without creating and removing an instance of the generator.
* | Merge topic 'per-config-EXCLUDE_FROM_DEFAULT_BUILD'Brad King2012-11-201-4/+7
|\ \ | |/ |/| | | | | | | | | | | 739f166 Serialize tests for EXCLUDE_FROM_DEFAULT_BUILD e31d83b Define property EXCLUDE_FROM_DEFAULT_BUILD d1f8828 Add property EXCLUDE_FROM_DEFAULT_BUILD_<CONFIG> b777272 Add tests for EXCLUDE_FROM_DEFAULT_BUILD
generated by cgit v0.12 at 2024-12-26 03:52:26 (GMT)