summaryrefslogtreecommitdiffstats
path: root/Source/cmVisualStudio10TargetGenerator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* VS11: Simplify external object file handling (#13831)Brad King2013-01-071-5/+20
| | | | | | | | | | | | | | | | | Since commit 9a6ff950 (Fix for bug where VS2010 did not use .obj files as part of the build, 2011-04-01) and commit b291d9e7 (VS10: Fix external objects generated outside target, 2012-03-19) we try to detect whether an external object file is also a custom command output in the same target. This is because VS10 includes .obj custom command outputs on the link line by default. VS 11 supports a "<LinkObjects ...>false</LinkObjects>" setting in custom command rules to tell VS not to link the outputs. From the VS help: Specify whether the Inputs and output files with specific extensions (.obj, .lib, .res, .rsc) are passed to the linker. Treat all external object files the same and add "<Object>" settings for them.
* Revert "Move GetLinkInformation to cmGeneratorTarget"Stephen Kelly2012-11-211-1/+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 ambiguity warning regarding use of && and ||.Stephen Kelly2012-11-131-2/+2
| | | | | | | | | | This is not ambiguous to the compiler, but it may seem ambiguous to the reader. From reading 3a53005f (Build object library targets in VS), 5484550a (Detect and set Unicode character set in VS 10), and 9e01aefd (VS: Add support for WinRT project properties (#12930)), this appears to be the intentional semantic.
* Resolve warnings about used enum values in switch blocks.Stephen Kelly2012-11-131-0/+3
|
* Resolve warnings about unused variables.Stephen Kelly2012-11-071-1/+0
|
* VS10: Honor /DELAYSIGN and /KEYFILE flags (#13601)Brad King2012-10-261-0/+17
| | | | | | | Fix the VS 10 link flag map to name the project file entries correctly. The VS 11 link flag map already has the correct names. Generate the entries in the <PropertyGroup> along with incremental linking options. Drop them from the <Link> element because VS does not use them.
* VS10: Refactor link options collectionBrad King2012-10-261-81/+61
| | | | | | Avoid collecting the link options twice. Collect them once in a LinkOptions member and use it from both places. We already do this for compiler options with the ClOptions member.
* Fix config-specific INCLUDE_DIRECTORIES in multi-config generatorsStephen Kelly2012-10-171-3/+4
| | | | | | | | 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.
* Merge topic 'vs-pdb-output'Brad King2012-10-011-5/+3
|\ | | | | | | | | | | | | | | 2ccca05 Run PDBDirectoryAndName test on MSVC and Intel efc83b3 Document that PDB_(NAME|OUTPUT_DIRECTORY) are ignored for VS 6 b294457 Verify that PDB_(NAME|OUTPUT_DIRECTORY) are honored in test 3f60dbf Add PDB_OUTPUT_DIRECTORY and PDB_NAME target properties (#10830)
| * Add PDB_OUTPUT_DIRECTORY and PDB_NAME target properties (#10830)Yuchen Deng2012-09-251-5/+3
| | | | | | | | | | | | | | This enables changing the name and output folder of the debug symbol files produced by MS compilers. Inspired-by: Thomas Bernard <thomas.bernard@ipetronik.com>
* | Return a std::string from GetCompileDefinitions.Stephen Kelly2012-09-211-2/+3
| |
* | Port remaining code to GetCompileDefinitions().Stephen Kelly2012-09-211-9/+3
| |
* | Move GetIncludeDirectories to cmGeneratorTarget.Stephen Kelly2012-09-191-1/+2
| |
* | Move GetLinkInformation to cmGeneratorTargetStephen Kelly2012-09-191-1/+1
|/
* Merge topic 'vs11-flag-table'David Cole2012-08-241-4/+31
|\ | | | | | | | | | | 9b2dda5 VS11: Generate flag tables from MSBuild V110 tool files 4cb99b1 cmparseMSBuildXML: Include DisplayName in the output
| * VS11: Generate flag tables from MSBuild V110 tool filesBrad King2012-08-221-4/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | Run cmparseMSBuildXML.py on cl.xml, lib.xml, and link.xml to generate our flag tables: python cmparseMSBuildXML.py -x ".../MSBuild/Microsoft.Cpp/v4.0/V110/1033/cl.xml" > cmVS11CLFlagTable.h python cmparseMSBuildXML.py -x ".../MSBuild/Microsoft.Cpp/v4.0/V110/1033/lib.xml" > cmVS11LibFlagTable.h python cmparseMSBuildXML.py -x ".../MSBuild/Microsoft.Cpp/v4.0/V110/1033/link.xml" > cmVS11LinkFlagTable.h Fix up the declaration names at the top of each file. Finally, teach cmVisualStudio10TargetGenerator to select the version of the table matching the version of VS.
* | Merge topic 'VS10-PrecompiledHeader-default'David Cole2012-08-241-0/+1
|\ \ | | | | | | | | | | | | f0ae381 VS: Disable precompiled headers unless enabled by project (#12930)
| * | VS: Disable precompiled headers unless enabled by project (#12930)Brad King2012-08-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In VS 11 the WindowsAppContainer element enabled by the VS_WINRT_EXTENSIONS property activates precompiled header support automatically if no PrecompiledHeader setting is specified. For VS 10 and 11 set PrecompiledHeader to "NotUsing" explicitly by default unless overridden by a project-specified flag. Suggested-by: Eugene Golushkov <eugene_gff@ukr.net>
* | | Merge topic 'VS11-WinRT-project-issue-12930'David Cole2012-08-241-1/+2
|\ \ \ | |/ / | | / | |/ |/| 4c9ae47 VS11: Rename 'Immersive' to 'WindowsAppContainer' (#12930)
| * VS11: Rename 'Immersive' to 'WindowsAppContainer' (#12930)Brad King2012-08-211-1/+2
| | | | | | | | | | | | | | | | | | | | Since commit 9e01aefd (VS: Add support for WinRT project properties, 2012-02-03) CMake generates for VS 11 projects the 'Immersive' element for the VS_WINRT_EXTENSIONS target property. That was based on the VS 11 preview version. The final version renamed the element to 'WindowsAppContainer', so generate that instead. Suggested-by: Eugene Golushkov <eugene_gff@ukr.net>
* | Remove trailing whitespace from most CMake and C/C++ codeKitware Robot2012-08-131-56/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/ \+$//'
* | VS10: Generate relative source paths when possible (#12570)Brad King2012-04-271-4/+15
| | | | | | | | | | | | | | | | | | | | Since commit ed0075bd (Use relative paths for custom command inputs, 2011-06-22) CMake generates full paths to source files in VS 10 project files to avoid trouble with deep source/build tree paths. However, the VS 10 IDE will not populate the source file property dialog for a file referenced by full path. Instead use a relative path when possible. When not possible produce a detailed warning explaining the problem and suggesting use of shorter directory paths.
* | VS11: Do not use source path conversion workaround specific to VS 10Brad King2012-04-271-7/+22
| | | | | | | | | | | | | | | | | | CMake <= 2.8.4 generated VS 10 project files with a relative path to source files. Then commit ed0075bd (Use relative paths for custom command inputs, 2011-06-22) switched to using relative paths only for source files holding custom commands and full paths for other sources. This behavior was inhereted by the VS 11 generator but is not needed so use the workaround only for exactly VS 10. Explain the behavior in comments.
* | VS10: Convert paths normally unless forced to relativeBrad King2012-04-271-19/+20
| | | | | | | | | | | | | | Most CMake generators produce relative paths within the build tree and full paths to files outside the build tree. Make VS 10 and VS 11 project files consistent with this approach except for paths forced to be relative to work around a VS 10 bug.
* | VS10: Simplify vcxproj.filter file generationBrad King2012-04-271-63/+15
| | | | | | | | | | | | | | | | | | Remove the duplicate source file classification logic used to generate the filter files. Instead record during the main vcxproj file generation the source files generated for each tool. Also record whether or not each source file is converted to a relative path. Use the recorded result during filter generation to ensure consistency between the project file and filter file.
* | VS10: Refactor custom commands to use WriteSourceBrad King2012-04-271-13/+19
| | | | | | | | | | All other source file elements are already written through WriteSource. Refactor custom command source element generation into WriteSource too.
* | VS10: Avoid creating .rule files next to outputs (#13141)Brad King2012-04-181-1/+2
| | | | | | | | | | | | | | | | Hide custom command .rule files inside the CMakeFiles directory. Ensure a short, deterministic, and unique name by using a hash of the directory path containing the output file. Preserve the file name so the entry in the IDE is human-readable. Clarify the comment that explains why the rule file must be created on disk.
* | 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.
* VS10: Fix external objects generated outside target (#13047)Brad King2012-03-201-13/+4
| | | | | | | | | | | | | Commit 9a6ff950 (Fix for bug where VS2010 did not use .obj files, 2011-04-01) assumed that if an external object is GENERATED that it is the output of a custom command in the current target. If it is generated by another target then VS will not automatically include the external object in the current target. This bug was preserved by the refactoring in the parent commit. Instead use <None> for external objects generated by a custom command in the current target and <Object> for all other external objects. Update the ExternalOBJ test to cover this case.
* Simplify cmVisualStudio10TargetGenerator source classificationBrad King2012-03-191-87/+56
| | | | | | Combine WriteCLSources and WriteObjSources into a single method. Use the cmGeneratorTarget source classification to simplify tool selection for each source file. Extend the classification to handle .idl files.
* Add $<TARGET_OBJECTS:...> expression to use an object libraryBrad King2012-03-161-0/+44
| | | | | | 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-12/+26
| | | | | | | | 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-10/+3
| | | | | | 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.
* Simplify cmVisualStudio10TargetGenerator using cmGeneratorTargetBrad King2012-03-091-27/+10
| | | | | Use CustomCommands and ModuleDefinitionFile computed in the latter instead of recomputing them from the original target source files.
* Merge branch 'cleanup-object-file-names' into object-libraryBrad King2012-03-091-7/+1
|\
| * VS: Simplify object name computationBrad King2012-03-061-7/+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.
* | Merge topic 'fix-12189-support-SBCS-in-VS'David Cole2012-03-081-0/+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)
| * | Visual Studio: Allow setting Single Byte Character Set (#12189)Aaron C. Meadows2012-02-171-0/+5
| |/ | | | | | | | | | | | | For Visual Studio using the Preprocessor Define _SBCS. This behavior is similar to the way that _UNICODE and _MBCS work already. Added tests to confirm this behavior.
* | Extract and use the INCLUDE_DIRECTORIES target properties.Stephen Kelly2012-02-221-1/+1
|/ | | | | | | | | Eliminate callers of cmMakefile::GetIncludeDirectories. All callers of GetIncludeDirectories should go through the local generator object. Only the local generator calls cmTarget::GetIncludeDirectories directly.
* VS: Simplify ;-separated attribute value parsingBrad King2012-02-031-34/+20
| | | | | | | An implementation ;-separated list parsing was added by commit a1f976ce (VS: Add support for three new project properties, 2011-11-23) and again by commit 9e01aefd (VS: Add support for WinRT project properties, 2012-02-03). Refactor both instances to use ExpandListArgument.
* VS: Add support for WinRT project properties (#12930)Eugene Golushkov2012-02-031-1/+37
| | | | | | | | VS_WINRT_EXTENSIONS: Boolean property that correspond to "Enable Tailored Features" in Visual Studio 11 IDE. VS_WINRT_REFERENCES: Semicolon-delimited list of *.winmd references to add to the project, which creates a new <ItemGroup>.
* VS10: Fix /pdb option vcxproj element name (#12328)Brad King2012-01-091-1/+1
| | | | | The compiler tool uses "ProgramDataBaseFileName" but the linker tool uses just "ProgramDataBaseFile". Fix the generator accordingly.
* VS: Add support for three new project properties (#12586)Aaron Ten Clay2011-11-281-1/+56
| | | | | | | | | | | VS_GLOBAL_PROJECT_TYPES: A string containing UUIDs to embed in the Visual Studio project file under <ProjectTypes>. VS_GLOBAL_KEYWORD: Allows specification of a keyword like "ManagedCProj" instead of the default "Win32Proj", under <Keyword> VS_DOTNET_REFERENCES: Semicolon-delimited list of .NET references to add to the project, which creates a new <ItemGroup>.
* Merge topic 'vs-version-ivar'David Cole2011-11-151-4/+4
|\ | | | | | | | | | | c92ffec Enumerate VS11 version explicitly in local generators 1be4b6f Order VS local generator Version ivar values consistently
| * Order VS local generator Version ivar values consistentlyBrad King2011-11-141-4/+4
| | | | | | | | | | | | | | | | | | | | | | Move the Version member to the top cmLocalVisualStudioGenerator class and set it consistently for instances created by all the global generator versions. Use an enumeration type with values scaled by a factor of 10 so we can handle VS 7.1 without out-of-order numbers. VS 7.1 support for SuppressStartupBanner was broken by commit 25116a3c (Fix CMAKE_VERBOSE_MAKEFILE for VS10 vcxproj files, 2011-10-11) because it assumed comparison of VS version numbers works. Now it does.
* | Merge topic 'fix-11213-vs10-mfc-support'David Cole2011-11-151-4/+12
|\ \ | |/ |/| | | | | | | | | | | | | 537020f Tests: Nudge MFC test to pass on VS 6 dashboards (#11213) 51f442e VS11: Update InstallRequiredSystemLibraries.cmake for VS11 (#11213) d85ab7a Tests: Add environment logging to the MFC test (#11213) 011694c VS10: Use expected values for UseOfMfc (#11213) a2e6d24 Tests: Fix MFC test to work with VS 10 and later (#11213)
| * VS10: Use expected values for UseOfMfc (#11213)David Cole2011-11-041-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Use expected values for the UseOfMfc xml element in VS 10 .vcxproj files. CMAKE_MFC_FLAG=1 maps to "Static" CMAKE_MFC_FLAG=2 maps to "Dynamic" all other values map to "false" Thanks to Randy Schott and McBen for their patches which served as inspiration and motivation for getting this done. See also http://public.kitware.com/Bug/view.php?id=11224
* | VS: Add VS_SCC_AUXPATH target property (#12549)Robert Dailey2011-11-011-1/+9
|/ | | | Maps to SccAuxPath tag in VCPROJ files.
* VS10: Avoid unnecessary rebuilds for custom commandsDavid Cole2011-08-181-1/+1
| | | | | Thanks to James Bigler for pointing this out on the cmake-developers mailing list...
* Merge topic 'intel_fortran_vs2010'David Cole2011-08-161-0/+7
|\ | | | | | | | | 3c53fbb Fix custom commands in VS2010 Fortran projects using CFG_INTDIR and test.
generated by cgit v0.12 at 2025-01-16 05:11:11 (GMT)