summaryrefslogtreecommitdiffstats
path: root/Source/cmLocalVisualStudio6Generator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* cmTarget: Rename old-style link dependencies code as "ForVS6"Brad King2014-07-141-1/+2
| | | | | | The old link dependency analysis is now needed only for the VS 6 generator code delimited by CM_USE_OLD_VS6 to support project-provided project templates. Rename the related cmTarget members to be "ForVS6".
* cmTarget: Make the source files depend on the config.Stephen Kelly2014-04-021-4/+33
| | | | | | | | | | | | | | | | | 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.
* cmTarget: Allow any generator expression in SOURCES property.Stephen Kelly2014-04-021-0/+10
| | | | | | | | | | | | | | | | Remove use of UseObjectLibraries from Makefile and Ninja generators. It is not needed now because those generators use GetExternalObjects which already contains the objects from object libraries. The VS10 generator calls both the UseObjectLibraries and the GetExternalObjects methods. Ensure that duplicates are not created by skipping objects from object libraries in handling of GetExternalObjects. Similarly, fix VS6, VS7 and Xcode object handling by skipping external objects from OBJECT_LIBRARY usage as appropriate. The error message in the BadSourceExpression1 test is now reported by the generator expression evaluator, so it has different text.
* cmTarget: Use string API to add sources to cmTarget objects.Stephen Kelly2014-03-311-3/+3
| | | | | Continue to call GetOrCreateSource where necessary to create cmSourceFile objects which have the GENERATED attribute set.
* Generalize cmCustomCommandGenerator to more fieldsBrad King2014-03-121-16/+23
| | | | | | | Until now the cmCustomCommandGenerator was used only to compute the command lines of a custom command. Generalize it to get the comment, working directory, dependencies, and outputs of custom commands. Update use in all generators to support this.
* cmCustomCommand: Return std::string from GetWorkingDirectoryBrad King2014-03-121-1/+1
|
* stringapi: Use strings for dependency informationBen Boeckel2014-03-081-1/+1
|
* stringapi: Pass configuration names as stringsBen Boeckel2014-03-081-8/+8
|
* strings: Remove cmStdString referencesBen Boeckel2014-03-081-3/+3
| | | | | | | | | | | 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 in target nameBen Boeckel2014-03-081-11/+11
|
* stringapi: Use strings for the languagesBen Boeckel2014-03-081-22/+19
|
* cmMakefile: Make FindSourceGroup const.Stephen Kelly2014-01-221-2/+2
| | | | | Return a pointer instead of a reference. This allows making the accessor const with the least impact.
* cmTarget: Make GetSourceFiles populate an out-vector parameter.Stephen Kelly2014-01-091-1/+2
| | | | | In a future patch, this will also be populated with extra sources from the linked dependencies.
* cmGeneratorTarget: Add methods to access source file groups.Stephen Kelly2014-01-091-2/+2
| | | | | These methods and others will be able to get a config parameter later to implement the INTERFACE_SOURCES feature.
* Use cmsys::[io]fstream instead of cmsys_ios::[io]fstream.Clinton Stimpson2014-01-071-6/+7
| | | | | Also use SystemTools::Fopen() instead of fopen(). This is to eventually support utf-8 filenames.
* Merge topic 'INTERFACE_LIBRARY-target-type'Brad King2013-10-081-1/+9
|\ | | | | | | | | | | | | 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-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | VS6: Add some delimiting between error message and content.Stephen Kelly2013-09-121-2/+2
|/
* VS 6,7: Refactor local generators to avoid GetSourceFileWithOutputBrad King2013-08-061-10/+8
| | | | | | Use the cmSourceFile returned by AddCustomCommandToOutput instead of throwing out the return value and looking it up with GetSourceFileWithOutput.
* VS6: Add handling of CMAKE_*_LINKER_FLAGS_<CONFIG> variablesPatrick Gansterer2013-07-311-6/+30
| | | | | Read the content of the config specific linker flags in the Visual Studio 6 generator too.
* Add support for CMAKE_STATIC_LINKER_FLAGSPatrick Gansterer2013-07-311-32/+33
| | | | | Add the content of this variable to the target specific linker flags as we do with the other CMAKE_*_LINKER_FLAGS variables already.
* Refactor cmTarget::GetCompileDefinitions to use an out-vector, not a string.Stephen Kelly2013-07-111-15/+5
| | | | Refactor to create AddCompileDefinitions.
* Refactor target COMPILE_OPTIONS and COMPILE_FLAGS handlingBrad King2013-06-271-26/+8
| | | | | | | | | | | | Replace the cmLocalGenerator GetCompileOptions method with an AddCompileOptions method since all call sites of the former simply append the result to a flags string anyway. Add a "lang" argument to AddCompileOptions and move the CMAKE_<LANG>_FLAGS_REGEX filter into it. Move the call sites in each generator to a location that has both the language and configuration available. In the Makefile generator this also moves the flags from build.make to flags.make where they belong.
* Add whitespace after colons in error messages.Stephen Kelly2013-06-211-2/+2
|
* Add cmLocalGenerator::GetCompileOptions.Stephen Kelly2013-06-021-1/+20
| | | | | | Currently it only adds the contents of the COMPILE_FLAGS target property, but it can be extended to handle a new COMPILE_OPTIONS generator expression enabled property.
* VS6: Rename some variables to correspond to config values.Stephen Kelly2013-06-021-10/+10
| | | | This simplifies population of the compile flags.
* Fix the evaluation of per-config COMPILE_DEFINITIONS (#14037)Stephen Kelly2013-03-251-1/+1
| | | | | | | | | | | | | | The API for retrieving per-config COMPILE_DEFINITIONS has long existed because of the COMPILE_DEFINITIONS_<CONFIG> style properties. Ensure that the provided configuration being generated is also used to evaluate the generator expressions in cmTarget::GetCompileDefinitions. Both the generic COMPILE_DEFINITIONS and the config-specific variant need to be evaluated with the requested configuration. This has the side-effect that the COMPILE_DEFINITIONS does not need to be additionally evaluated with no configuration, so the callers can be cleaned up a bit too.
* Merge topic 'vs6-rule-files'Brad King2013-02-051-0/+3
|\ | | | | | | | | 0f24a66 VS 6: Create .rule file directory before file
| * VS 6: Create .rule file directory before fileBrad King2013-02-031-0/+3
| | | | | | | | | | The VS 6 IDE wants .rule files to exist in order to run the rule attached to it. When creating the dummy .rule file make sure the directory exists.
* | Move GetCompileDefinitions to cmTarget.Stephen Kelly2013-01-291-9/+5
|/
* Revert "Move GetLinkInformation to cmGeneratorTarget"Stephen Kelly2012-11-211-3/+1
| | | | | | | As we can't move all linking related code from cmTarget, it makes sense to reverse the move in some cases. This reverts commit 4f5384e75c6a00d110d3fa3f555a3f6a4f31bb46.
* Resolve warnings about shadowing parameters and local variables.Stephen Kelly2012-11-131-6/+6
|
* Resolve warnings about used enum values in switch blocks.Stephen Kelly2012-11-131-0/+2
|
* Fix config-specific INCLUDE_DIRECTORIES in multi-config generatorsStephen Kelly2012-10-171-5/+21
| | | | | | | | Commit 08cb4fa4 (Process generator expressions in the INCLUDE_DIRECTORIES property, 2012-09-18) contained an incorrect assumption that CMAKE_BUILD_TYPE was set on the makefile for each generated configuration in multi-config generators. Fix that by making the GetIncludeDirectories API depend on the config.
* Add a wrapper for accessing config-specific compile-definitions.Stephen Kelly2012-09-191-5/+9
|
* Append the COMPILE_DEFINITIONS from the Makefile to all targets.Stephen Kelly2012-09-191-16/+0
| | | | | | | | This way we don't need to check the definitions from the Makefile when generating later, and can more easily add generator expressions. Duplication is not a problem as the definitions are de-duplicated before generating.
* Move GetIncludeDirectories to cmGeneratorTarget.Stephen Kelly2012-09-191-1/+4
|
* Move GetLinkInformation to cmGeneratorTargetStephen Kelly2012-09-191-1/+3
|
* Don't duplicate -D defines sent to the compiler.Stephen Kelly2012-08-201-31/+61
| | | | | | | | | | | There is no need to do so. Be consistent with include directories and ensure uniqueness. This requires changing the API of the cmLocalGenerator::AppendDefines method, and changing the generators to match. The test unfortunately can't test for uniqueness, but it at least verifies that nothing gets lost.
* Remove trailing whitespace from most CMake and C/C++ codeKitware Robot2012-08-131-93/+93
| | | | | | | | | | | | | | | | | 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/ \+$//'
* Cleanup custom command .rule file internal handlingBrad King2012-04-181-1/+1
| | | | | | | | Teach cmMakefile::AddCustomCommandToOutput to return the cmSourceFile instance to which the custom command is attached. Use the return value instead of separately adding a .rule extension and searching for the source. Mark CMake-generated .rule files explicitly with a property instead of trusting the file extension.
* VS: Add CMakeLists.txt re-run rules at start of generationBrad King2012-03-281-12/+17
| | | | | | | | | | | | | | | 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 $<TARGET_OBJECTS:...> expression to use an object libraryBrad King2012-03-161-1/+35
| | | | | | For now do not allow an OBJECT library to reference other object libraries. Teach cmTarget::ComputeLinkImplementation to include the languages of object libraries used by a target.
* Build object library targets in VSBrad King2012-03-131-9/+32
| | | | | | | | Treat OBJECT libraries as STATIC libraries. The VS project file format provides no way to avoid running the librarian so hide the resulting .lib away next to the object files as it should never be referenced. The object files will be left behind for reference by other targets later.
* Pre-compute object file names before VS project generationBrad King2012-03-091-29/+35
| | | | | | 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.
* Merge branch 'cleanup-object-file-names' into object-libraryBrad King2012-03-091-12/+1
|\
| * VS: Simplify object name computationBrad King2012-03-061-1/+1
| | | | | | | | | | | | | | | | Simplify cmLocalVisualStudioGenerator::ComputeObjectNameRequirements to loop over the original vector of source files instead of recursively traversing source groups just to find the same files. Drop from cmVisualStudio10TargetGenerator::ComputeObjectNames temporary source group calculation now that it is not needed for computing object names.
| * Remove unused partial OBJECT_FILES property implementationBrad King2012-03-061-11/+0
| | | | | | | | | | | | | | Remove partial implementation added by commit ca0230a3 (check in initial conv library stuff, 2007-02-16) since it was never finished. It does not make sense for multi-configuration generators since no specific build configuration is processed at CMake time.
* | Merge topic 'fix-12189-support-SBCS-in-VS'David Cole2012-03-081-3/+5
|\ \ | | | | | | | | | | | | | | | | | | b28e7fa VS6: Avoid SBCS test on VS6 (#12189) df19b9c VS6: Avoid _MBCS define when _SBCS is defined (#12189) ba89e92 Visual Studio: Allow setting Single Byte Character Set (#12189)
generated by cgit v0.12 at 2024-12-26 07:05:10 (GMT)