summaryrefslogtreecommitdiffstats
path: root/Source/cmVisualStudio10TargetGenerator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* Merge topic 'doc-improvements'Brad King2013-05-161-0/+15
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | 7cc2805 Docs: Clarify wording "flag used" => "flag (to|will) be used" 2378a69 Docs: Clarify that CMAKE_*_(PREFIX|SUFFIX) affect filenames 56ca34d Docs: Update description of CMAKE_(BUILD_TYPE|CONFIGURATION_TYPES) 2bab472 VS10: add detailed comment about MIDL processing e619111 Explain distribution of Win9x binary on all Windows versions. 5ca4336 FindwxWidgets: add DOC strings with usual style f57800d Fix spelling and typos (product names) bf019d7 Fix spelling and typos (non-binary) ddac8d3 Fix spelling and typos (affecting binary data / module messages) 86832ce Fix spelling and typos (affecting users)
| * VS10: add detailed comment about MIDL processingAndreas Mohr2013-05-071-0/+15
| |
* | VS: Separate compiler and linker PDB files (#11899, #14062)Brad King2013-04-051-8/+0
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The MS tools create two types of PDB files as explained here: http://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.71%29.aspx http://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.80%29.aspx http://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.90%29.aspx http://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.100%29.aspx One is created by the compiler (/Fd) and the other by the linker (/pdb). The two options should not specify the same file. Split them up. In the VS IDE generators, simply drop ProgramDataBaseFileName to take the VS default "/Fd$(IntDir)vc$(PlatformToolsetVersion).pdb". In the Makefile generators, set "/Fd" on the compile line to be the directory containing object files (with a trailing slash the compiler will add the "vc$(PlatformToolsetVersion).pdb" filename automatically). Drop the /Fd option from the exe link command line and add "/pdb" instead (already done for dll linking). Update these rules for both MSVC and Intel tools. Drop support for PDB_OUTPUT_DIRECTORY and PDB_NAME in STATIC libraries because the generated .pdb files are only from /Fd and not real linker-generated .pdb files. Update documentation to clarify that the PDB_* properties are only for linker .pdb files. This regresses the PDBDirectoryAndName test for STATIC libraries. Since it is not clear at this time what should be done for STATIC library .pdb files, comment out the relevant portion of the test and leave a TODO comment.
* Fix the evaluation of per-config COMPILE_DEFINITIONS (#14037)Stephen Kelly2013-03-251-2/+0
| | | | | | | | | | | | | | 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.
* VS 10: Fix CMAKE_<LANG>_STACK_SIZE implementation (#13968)Brad King2013-03-041-1/+1
| | | | | | | | | Use the /STACK: flag to pass the value through flag parsing so that the generator converts it to the StackReserveSize project file option. The option was accidentally left out by commit 7491f529 (first pass at VS 10, 2009-06-25). Suggested-by: goatboy160@yahoo.com
* Move GetCompileDefinitions to cmTarget.Stephen Kelly2013-01-291-2/+2
|
* 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
generated by cgit v0.12 at 2025-01-27 01:40:57 (GMT)