summaryrefslogtreecommitdiffstats
path: root/Source/cmGlobalVisualStudio7Generator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* Encoding: Write Visual Studio solution file with BOM.Clinton Stimpson2014-12-271-0/+5
| | | | | | | | When configured to use UTF-8 internally, add a UTF-8 BOM to generated .sln files for Visual Studio to correctly handle them. Otherwise, some versions of Visual Studio will read them as ANSI encoded files.
* VS: Implement CMAKE_GENERATOR_PLATFORM for VS >= 8Brad King2014-09-051-3/+14
| | | | | | | | | 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-4/+10
| | | | | | 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/+1
| | | | | | | | 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.
* cmGlobalVisualStudio7Generator: Remove unused variableBrad King2014-07-221-1/+0
|
* VS: Delay platform definitions until system name is knownBrad King2014-07-171-2/+3
| | | | | | | 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-1/+8
| | | | | | | 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.
* VS: Remove unused parameter of WriteTargetConfigurationsBrad King2014-06-131-2/+1
| | | | | The cmGlobalVisualStudio7Generator::WriteTargetConfigurations 'root' parameter is no longer used, so remove it.
* VS: Fix subproject .sln dependencies on custom targetsBrad King2014-06-121-27/+12
| | | | | | | | | | | | | | | | | | | | | | 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/+31
| | | | | Move the IsDependedOn method to cmGlobalVisualStudio7Generator since that is the only caller.
* Merge topic 'vs-vcproj-bool-case'Brad King2014-05-291-3/+3
|\ | | | | | | | | b684ce58 VS: Use lower-case boolean values in VS 7-9 (#14927)
| * VS: Use lower-case boolean values in VS 7-9 (#14927)Mark Salisbury2014-05-281-3/+3
| | | | | | | | | | | | | | The VS 7-9 IDEs parse .vcproj file boolean values in lower or upper case. The .NET XML parsing chokes on anything but "true", "false", "0", "1". Teach our generators to use lower-case names since they will work for both parsers. Our VS >= 10 flag tables already use lower-case.
* | Encoding: If configured, write Visual Studio project files as UTF-8.Clinton Stimpson2014-03-141-1/+13
| |
* | stringapi: Use strings for program pathsBen Boeckel2014-03-081-1/+1
| |
* | stringapi: Use strings for generator namesBen Boeckel2014-03-081-9/+13
| |
* | 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-4/+4
| |
* | 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-9/+10
| |
* | stringapi: Use strings in target nameBen Boeckel2014-03-081-6/+7
|/
* VS: Teach include_external_msproject about non-C++ projects (#14661)David Golub2013-12-201-1/+36
| | | | | | 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-7/+7
|
* Windows: Use wide-character system APIsClinton Stimpson2013-12-091-4/+5
| | | | | Make CMake compile with -DUNICODE. Make it possible for the 8 bit encoding to eventually be UTF-8 instead ANSI.
* Merge topic 'cleanup-build-commands'Brad King2013-12-051-0/+8
|\ | | | | | | | | | | e420124 CMakeDetermineCompilerId: Use CMAKE_VS_(DEVENV|MSBUILD|MSDEV)_COMMAND 0c55729 VS: Add CMAKE_VS_(DEVENV|MSBUILD|MSDEV)_COMMAND variables
| * VS: Add CMAKE_VS_(DEVENV|MSBUILD|MSDEV)_COMMAND variablesBrad King2013-12-041-0/+8
| | | | | | | | | | | | | | | | 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.
* | INTERFACE_LIBRARY: Avoid codepaths which set unneeded properties.Stephen Kelly2013-11-251-0/+8
|/ | | | | | | | | | | | | 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.
* Teach GenerateBuildCommand to find its own make programBrad King2013-11-181-1/+15
| | | | | | | | Add a cmGlobalGenerator::SelectMakeProgram method to select a caller-provided make program, the CMAKE_MAKE_PROGRAM cache entry, or a generator-provided default. Call it from all implementations of the GenerateBuildCommand method with the corresponding generator's default, if any.
* VS: Add internal APIs to find MSBuild, devenv/VCExpress, and msdevBrad King2013-11-181-0/+28
| | | | | 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-42/+22
| | | | | | | | | 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.
* VS: Detect Intel Fortran compiler id and versionBrad King2013-10-181-1/+0
| | | | | | Teach CMakeDetermineCompilerId to use a .vfproj project file to build the Fortran compiler id source file under the Visual Studio generators.
* VS: Expose Intel Fortran .vfproj format version to CMake languageBrad King2013-10-181-0/+42
| | | | | | Lookup the Intel VS plugin version on demand in the VS global generator, compute the corresponding .vfproj format version number, and memoize it. Add it as a CMAKE_VS_INTEL_Fortran_PROJECT_VERSION platform definition.
* Drop the 'Full' field from cmDocumentationEntryBrad King2013-10-161-1/+0
| | | | | We need only 'Brief' for usage documentation. We no longer have builtin 'Full' documentation, which is now in Help/*/*.rst files.
* 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: Replace ArchitectureId with PlatformNamePatrick Gansterer2013-08-051-15/+8
| | | | | | | | 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-4/+25
| | | | | Move the code which sets CMAKE_VS_PLATFORM_NAME from cmGlobalVisualStudio8Generator to cmGlobalVisualStudio7Generator.
* Merge topic 'vs-configurations'Brad King2013-05-161-0/+10
|\ | | | | | | | | 42bb42d VS: Always initialize CMAKE_CONFIGURATION_TYPES in IDE generators
| * VS: Always initialize CMAKE_CONFIGURATION_TYPES in IDE generatorsBrad King2013-05-131-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | Initialize the CMAKE_CONFIGURATION_TYPES cache entry early during EnableLanguage like the Xcode generator does. Avoid depending on the MSVC compiler information module to do it. Otherwise code like project(MyProj NONE) sets CMAKE_CONFIGURATION_TYPES late (in GenerateConfigurations), and to only "Debug" and "Release" instead of the standard set of 4. Reported-by: Paul Smith <paul@mad-scientist.net>
* | Add projectDir parameter to GenerateBuildCommandPetr Kmoch2013-04-121-1/+3
|/ | | | | | | | Extend the cmGlobalGenerator::GenerateBuildCommand virtual method signature with a "projectDir" parameter specifying the top of the project build tree for which the build command will be generated. Populate it from call sites in cmGlobalGenerator::Build where a fully-generated build tree should be available.
* VS: Restore CMAKE_GENERATOR_FC variableBrad King2013-02-221-0/+1
| | | | | | | | | In commit bed6c388 (VS,Xcode: Remove unused CMAKE_GENERATOR_* variables, 2013-02-19) we removed this variable among others from the VS generator claiming they were all not used. In fact the Fortran compiler detection module CMakeDetermineFortranCompiler.cmake uses CMAKE_GENERATOR_FC even for the Visual Studio IDE generators because it does not use the full IDE compiler id detection like the C and C++ language files do.
* VS,Xcode: Remove unused CMAKE_GENERATOR_* variablesBrad King2013-02-191-3/+0
| | | | | | | Since the topic merged to master by commit 34a02846 (Merge topic 'ide-compiler-id', 2012-08-24), these variables are not used by CMakeDetermine*Compiler.cmake for VS and Xcode generators. Drop the code that sets them.
* VS: Added "Deploy" at project configuration for WindowsCE targetsPatrick Gansterer2012-11-271-3/+3
|
* Merge topic 'generator-factory'Brad King2012-11-201-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * 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' into vs-global-sectionsBrad King2012-11-161-19/+34
|\ \ | | | | | | | | | | | | Conflicts: Source/cmGlobalVisualStudio7Generator.h
| * | Add property EXCLUDE_FROM_DEFAULT_BUILD_<CONFIG>Petr Kmoch2012-11-131-19/+34
| |/ | | | | | | Allow EXCLUDE_FROM_DEFAULT_BUILD to be specified per configuration.
* | Implement properties VS_GLOBAL_SECTION_*Petr Kmoch2012-11-161-5/+67
|/ | | | | | Add properties VS_GLOBAL_SECTION_PRE_<name> and VS_GLOBAL_SECTION_POST_<name>, which can be used to generate custom GlobalSection-s in the .sln file.
* VS: Avoid empty, unreferenced solution folders... (#13571)David Cole2012-10-241-0/+2
| | | | | | | | | | | | | ...in generated sub-directory sln files. Thanks to rlandert for the bug report and proposed patch. The method WriteTargetsToSolution gets called possibly multiple times, once per sln file, (-> once per "project" command). Before accumulating folder names in VisualStudioFolders, clear it first, so it doesn't have stale entries in it from the previous sln file.
* VS: Simplify MSVC version reportingBrad King2012-08-301-1/+0
| | | | | | | | | Teach Windows-cl.cmake to use CMAKE_(C|CXX)_COMPILER_VERSION to set the "MSVC##" and MSVC_VERSION variables. It no longer needs the IDE generator to dictate the version or to detect the version by running the command-line tool for NMake and Ninja generators. Drop configuration of CMakeCPlatform.cmake and CMakeCXXPlatform.cmake from Windows-cl.cmake.in because all the results it saved are now cheap to compute every time.
generated by cgit v0.12 at 2024-11-05 07:16:41 (GMT)