summaryrefslogtreecommitdiffstats
path: root/Source/cmGlobalVisualStudioGenerator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* Use two-iterator std::set::insert where appropriate.Stephen Kelly2015-01-111-10/+2
|
* VS: Refactor CMAKE_FORCE_*64 platform definitionsBrad King2014-07-171-10/+0
| | | | | | | 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.
* cmTarget: Make the source files depend on the config.Stephen Kelly2014-04-021-1/+9
| | | | | | | | | | | | | | | | | Disallow the use of config-specific source files with the Visual Studio and Xcode generators. They don't have any way to represent the condition currently. Use the same common-config API in cmQtAutoGenerators. While it accepts config-specific files, it doesn't have to support multiple configurations yet. Loop over the configs in cmTargetTraceDependencies and cmGlobalGenerator::WriteSummary and consume all source files. Loop over the configs in cmComputeTargetDepends and compute the object library dependencies for each config.
* Merge topic 'target-objects-refactor'Brad King2014-03-171-43/+4
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6c9dd0ec cmGlobalGenerator: Make ComputeTargetObjects non-virtual c481fadc cmGeneratorTarget: Don't store ObjectSources for object libraries. f6da0440 cmLocalGenerator: Add ComputeObjectFilenames interface. 9ad804ac cmGeneratorTarget: Constify cmSourceFile* in containers. c725bb3c Constify some APIs in generators. dcfcd23e cmGeneratorTarget: Make GetSourceDepends const. 04cf50ff cmOSXBundleGenerator: Make MacOSXContentGeneratorType arg const. 6132d979 cmGeneratorTarget: Constify the AddExplicitObjectName API. bc512211 cmGeneratorTarget: Constify the AddObject API. cd43433d cmGlobalGenerator: Extract a ComputeTargetObjectDirectory interface. d5b2e33b Makefiles: Compute local object files on demand.
| * cmGlobalGenerator: Make ComputeTargetObjects non-virtualStephen Kelly2014-03-151-24/+0
| | | | | | | | | | | | | | | | Implement it in terms of the ComputeObjectFilenames virtual method on the local generators. Remove the reimplementation from the global generators which are now all functionally identical.
| * cmLocalGenerator: Add ComputeObjectFilenames interface.Stephen Kelly2014-03-131-34/+14
| | | | | | | | | | Implement it in the local generators and use it in the global generators.
| * cmGeneratorTarget: Constify cmSourceFile* in containers.Stephen Kelly2014-03-131-5/+5
| | | | | | | | | | Some of them will be used with other APIs which require value_type to be cmSourceFile const*.
| * cmGlobalGenerator: Extract a ComputeTargetObjectDirectory interface.Stephen Kelly2014-03-131-1/+6
| | | | | | | | Make it public for future external calls.
* | Encoding: If configured, write Visual Studio project files as UTF-8.Clinton Stimpson2014-03-141-1/+2
|/
* stringapi: Use strings for generator namesBen Boeckel2014-03-081-2/+2
|
* strings: Remove cmStdString referencesBen Boeckel2014-03-081-4/+4
| | | | | | | | | | | 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 in target nameBen Boeckel2014-03-081-3/+3
|
* OS X: Make sure RPATHs are unique to avoid possible corruption.Clinton Stimpson2014-02-031-0/+17
| | | | | | | | When using link_directories() and including CMAKE_CFG_INTDIR, one can end up with duplicate RPATHs in the binary which install_name_tool cannot fix without corrupting the binary. Also, the cmake_install.cmake file has been fixed to correctly handle these generator specific variables.
* cmGeneratorTarget: Add methods to access source file groups.Stephen Kelly2014-01-091-6/+8
| | | | | These methods and others will be able to get a config parameter later to implement the INTERFACE_SOURCES feature.
* Constify handling of target dependencies.Stephen Kelly2013-12-111-11/+13
|
* Windows: Use wide-character system APIsClinton Stimpson2013-12-091-33/+39
| | | | | Make CMake compile with -DUNICODE. Make it possible for the 8 bit encoding to eventually be UTF-8 instead ANSI.
* VS: Switch to internal CMAKE_MAKE_PROGRAM lookup by generatorsBrad King2013-11-181-0/+13
| | | | | | | | 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.
* 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-4/+0
| | | | | | | | 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().
* Fix spelling and typos (non-binary)Andreas Mohr2013-05-071-1/+1
|
* VS: Change variable type of ArchitectureId from const char* to stringPatrick Gansterer2012-11-261-2/+2
|
* VS: Add static method to get the base of the registryPatrick Gansterer2012-11-261-2/+9
|
* VS: Remove AddPlatformDefinitions from platform-specific generatorsPatrick Gansterer2012-11-191-0/+6
| | | | | Move the logic for handling platform specific defines from the subclasses into the cmGlobalVisualStudioGenerator base class.
* Resolve warnings about shadowing parameters and local variables.Stephen Kelly2012-11-131-1/+0
|
* VS: Simplify MSVC version reportingBrad King2012-08-301-6/+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.
* VS: Cleanup AddPlatformDefinitions() of Visual Studio generatorsPatrick Gansterer2012-08-221-0/+14
| | | | | Move adding of definitions into cmGlobalVisualStudioGenerator to share code and avoid duplicate architecture string literals.
* Remove trailing whitespace from most CMake and C/C++ codeKitware Robot2012-08-131-1/+1
| | | | | | | | | | | | | | | | | Our Git commit hooks disallow modification or addition of lines with trailing whitespace. Wipe out all remnants of trailing whitespace everywhere except third-party code. Run the following shell code: git ls-files -z -- \ bootstrap doxygen.config '*.readme' \ '*.c' '*.cmake' '*.cpp' '*.cxx' \ '*.el' '*.f' '*.f90' '*.h' '*.in' '*.in.l' '*.java' \ '*.mm' '*.pike' '*.py' '*.txt' '*.vim' | egrep -z -v '^(Utilities/cm|Source/(kwsys|CursesDialog/form)/)' | egrep -z -v '^(Modules/CPack\..*\.in)' | xargs -0 sed -i 's/ \+$//'
* VS: Add CMakeLists.txt re-run rules at start of generationBrad King2012-03-281-0/+10
| | | | | | | | | | | | | | | Since commit 328c0f65 (Simplify cmVisualStudio10TargetGenerator source classification, 2012-03-19) the VS 10 generator uses the cmGeneratorTarget source classification instead of directly getting the list of source files from the target. This accidentally dropped the CMakeLists.txt files from generated projects because they are added too late for cmGeneratorTarget. All generator-specific source files must be added to targets prior to cmGeneratorTarget construction. Refactor addition of the CMakeLists.txt files with CMake re-run custom commands to take place before normal generation begins, and therefore early enough to be included in the cmGeneratorTarget classification.
* Add OBJECT_LIBRARY target typeBrad King2012-03-131-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | This library type can compile sources to object files but does not link or archive them. It will be useful to reference from executable and normal library targets for direct inclusion of object files in them. Diagnose and reject the following as errors: * An OBJECT library may not be referenced in target_link_libraries. * An OBJECT library may contain only compiling sources and supporting headers and custom commands. Other source types that are not normally ignored are not allowed. * An OBJECT library may not have PRE_BUILD, PRE_LINK, or POST_BUILD commands. * An OBJECT library may not be installed, exported, or imported. Some of these cases may be supported in the future but are not for now. Teach the VS generator that OBJECT_LIBRARY targets are "linkable" just like STATIC_LIBRARY targets for the LinkLibraryDependencies behavior.
* Pre-compute and store target object directory in cmGeneratorTargetBrad King2012-03-121-0/+16
| | | | | | | Add cmGeneratorTarget::ObjectDirectory member to hold the value. In ComputeTargetObjects set the value to the full path to the target object directory including any necessary placeholder for the configuration name.
* Pre-compute object file names before VS project generationBrad King2012-03-091-1/+45
| | | | | | Implement cmGlobalGenerator::ComputeTargetObjects in the VS generator to pre-compute all the object file names. Use the results during generation instead of re-computing it later.
* Avoid passing string literal to char* typeBrad King2010-12-281-2/+3
|
* Use modern global dependency graph for VS < 8 depsBrad King2010-11-181-68/+136
| | | | | | | | | | | | | | | VS 7.1 and below have 2 behaviors that make the cmComputeTargetDepends result difficult to use for solution-level dependencies. Update the method cmGlobalVisualStudioGenerator::ComputeTargetDepends to document the behaviors and work around them. Commit 1a0c166a (Store direct dependencies in solutions for VS >= 8, 2010-08-20) isolated VS >= 8 from this computation so those versions should be unaffected. This change removes the last use of cmTarget::GetLinkLibraries for purposes other than backward compatibility with legacy interfaces (export_library_dependencies, VS 6 custom .dsp templates). Now the cmComputeTargetDepends results are used for all generators so global target dependency computation is fully centralized.
* Merge topic 'vs-project-groups'Brad King2010-09-081-0/+15
|\ | | | | | | | | e6ac0aa Add FOLDER target property, for IDEs (#3796)
| * Add FOLDER target property, for IDEs (#3796)David Cole2010-09-031-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This work was started from a patch by Thomas Schiffer. Thanks, Thomas! See the newly added documentation of the FOLDER target property for details. Also added global properties, USE_FOLDERS and PREDEFINED_TARGETS_FOLDER. See new docs here, too. By default, the FOLDER target property is used to organize targets into folders in IDEs that have support for such organization. This commit adds "solution folder" support to the Visual Studio generators. Currently works with versions 7 through 10. Also, use the new FOLDER property in the ExternalProject test and in the CMake project itself.
* | Refactor VS <= 7.1 utility-depends workaroundBrad King2010-08-241-164/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 438a7e2f (Fix utility dependencies for static libraries in VS generators, 2007-04-04) implemented utility-only dependencies between linkable targets by introducing an intermediate non-linkable target. We convert a dependency of the form foo -> bar to the form foo -> bar_UTILITY -> bar to prevent foo from including bar on its link line. Previously we added the extra "_UTILITY" targets explicitly among the project targets before dependency analysis was performed. Now we generate them separately at the last moment so that cmGlobalGenerator need not be aware of them.
* | Factor out duplicate VS target dependency codeBrad King2010-08-241-0/+58
|/ | | | | | Compute VS target dependencies in cmGlobalVisualStudioGenerator when the main global dependency analysis is done. Use these results in each of the VS generators instead of duplicating the analysis.
* Add alternative _UTILITY targets to all solutionsBrad King2009-10-011-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In VS 6, 7, and 7.1 solutions we implement add_dependencies(myexe mylib) # depend without linking by creating an intermediate mylib_UTILITY target with dependencies myexe -> mylib_UTILITY -> mylib to avoid linking myexe to mylib. Previously these extra targets were only added to the solution files in an ancestor directory of that defining mylib. For example, in the project: # CMakeLists.txt project(TOP) add_subdirectory(A) add_subdirectory(b) # A/CMakeLists.txt add_library(mylib ...) # B/CMakeLists.txt project(B) add_executable(myexe ...) add_dependencies(myexe mylib) the solution for TOP would have mylib_UTILITY but the solution for B would not even though it pulls in mylib through the dependency. This commit fixes solutions generated in other directories so that any solution that has mylib will get mylib_UTILITY also. See issue #9568.
* Move OrderedTargetDependSet into VS superclassBrad King2009-09-301-0/+28
| | | | | | We move cmGlobalVisualStudio7Generator::OrderedTargetDependSet up to cmGlobalVisualStudioGenerator so it can be re-used for other VS versions. See issue #9568.
* Convert CMake to OSI-approved BSD LicenseBrad King2009-09-281-14/+9
| | | | | | | This converts the CMake license to a pure 3-clause OSI-approved BSD License. We drop the previous license clause requiring modified versions to be plainly marked. We also update the CMake copyright to cover the full development time range.
* Create VS generator GetRegistryBase methodBrad King2009-09-161-0/+8
| | | | | | | | | This method returns the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\<version> A protected GetIDEVersion method retrieves the version-specific part of the key name.
* ENH: remove INCLUDE_EXTERNAL_MSPROJECT name hack, and use target properties ↵Bill Hoffman2009-07-141-13/+0
| | | | instead, fix VXExternalInclude test for VS10
* ENH: only 5 failing tests for VS 10Bill Hoffman2009-07-101-1/+17
|
* BUG: Fix issue #7088 - do not emit error messages when attempts to run ↵David Cole2008-07-301-3/+5
| | | | Visual Studio macros fail. You can still get the error output as messages if you want using --debug-output from the cmake command line.
* STYLE: fix warningBill Hoffman2008-05-011-1/+0
|
* ENH: add support for Intel Fortran Visual studio IDEBill Hoffman2008-04-301-0/+15
|
* ENH: Add code to support calling the VS reload macro from Visual Studio 7.1 ↵David Cole2008-02-151-17/+27
| | | | and 9.0 in addition to 8.0 sp1... Make new macros file with VS 7.1 so that it can be read by 7.1 and later. VS 7.1 does not appear to run the macros while a build is in progress, but does not return any errors either, so for now, the reload macro is not called when using 7.1. If I can figure out how to get 7.1 to execute the macro, I will uncomment the code in cmGlobalVisualStudio71Generator::GetUserMacrosDirectory() to activate executing the macros in VS 7.1, too.
* ENH: Updated exporting and importing of targets to support libraries and ↵Brad King2008-01-281-3/+3
| | | | | | | | | | | | | | | | | | configurations. - Created cmExportFileGenerator hierarchy to implement export file generation - Installed exports use per-config import files loaded by a central one. - Include soname of shared libraries in import information - Renamed PREFIX to NAMESPACE in INSTALL(EXPORT) and EXPORT() commands - Move addition of CMAKE_INSTALL_PREFIX to destinations to install generators - Import files compute the installation prefix relative to their location when loaded - Add mapping of importer configurations to importee configurations - Rename IMPORT targets to IMPORTED targets to distinguish from windows import libraries - Scope IMPORTED targets within directories to isolate them - Place all properties created by import files in the IMPORTED namespace - Document INSTALL(EXPORT) and EXPORT() commands. - Document IMPORTED signature of add_executable and add_library - Enable finding of imported targets in cmComputeLinkDepends
* ENH: Make static library targets depend on targets to which they "link" for ↵Brad King2007-12-211-0/+33
| | | | the purpose of build ordering. This makes the build order consistent for static and shared library builds. It is also useful when custom command inputs of one library are generated as custom commands outputs of another. It may be useful in the future for Fortran module dependencies. Implemented for Makefiles, Xcode, and VS 8 and above. Added sample code to do it for VS 7.1 and below, but left it disabled with comments explaining why. Likely it will never be needed on VS 7.1 or below anyway.
* STYLE: Fixed line-too-long. COMP: Fixed warnings about lossy conversions.Brad King2007-11-201-16/+31
|
generated by cgit v0.12 at 2024-10-13 09:03:44 (GMT)