summaryrefslogtreecommitdiffstats
path: root/Source/cmVisualStudio10TargetGenerator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* 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.
| * Fix custom commands in VS2010 Fortran projects using CFG_INTDIR and test.Bill Hoffman2011-08-031-0/+7
| | | | | | | | | | | | | | | | | | For custom commands in VS2010 Fortran projects the INTDIR variable is different than in the rest of the solution because Intel fortran still uses the old VS project files even in VS2010. So, we replace $(Configuration) directly in the project files. I have also added a FortranOnly test that tests this feature and is run on any generator that has Fortran abilities.
* | VS10: Add SCC supportSteven Velez2011-07-291-2/+17
|/ | | | | Honor the properties that were added for earlier versions of visual studio.
* Merge topic 'use_devenv_forvs2010'Brad King2011-06-241-1/+15
|\ | | | | | | | | | | | | | | 8555c2b Look for VCExpress as a possible build tool as well as devenv. ed0075b Use relative paths for custom command inputs. 38368d5 Revert "With very long file names, VS 2010 was unable to compile files." 8cd66dc Use devenv instead of msbuild for vs2010.
| * Use relative paths for custom command inputs.Bill Hoffman2011-06-221-10/+15
| | | | | | | | | | | | For source files we use full paths. This allows for longer directory names with VS2010. However, the use of full paths causes the GUI to not display the custom commands.
| * Revert "With very long file names, VS 2010 was unable to compile files."Bill Hoffman2011-06-211-1/+10
| | | | | | | | This reverts commit 945f2c2214bc80f513ed08ebe2c8003263a4ee56.
* | Fix for bug #11927, external project git clone step always runs vs10.Bill Hoffman2011-06-071-0/+11
|/ | | | | | | | | In cmMakefile.cxx GetCMakeCFGInitDirectory is replaced with GetCMakeFilesDirectory for .rule files. In some cases with external projects, that directory will not exist. With vs10 the .rule files must exist or the rule will run with every build. This fix creates the path that the .rule file is in. In addition, it is now a CMake error if the .rule file can not be created.
* VS10: Write header-only files in correct xml element (#11925)David Cole2011-05-231-5/+5
|
* Fix for bug where VS2010 did not use .obj files as part of the build.Bill Hoffman2011-04-011-5/+21
| | | | | | | For VS2010 if a precompiled .obj file was the output of a custom commad, it was used as part of the build. If it was not, then VS did not use it as part of the build. This commit updates the test to check for this issue, and fixes the problem. This fixes bugs #0011891 and
* With very long file names, VS 2010 was unable to compile files.Bill Hoffman2011-03-231-10/+1
| | | | | | | | At some point in the past VS 2010 failed some tests with custom commands when relative paths were not used. It seems that those problems have been fixed. However, the relative paths apparently are appended to the current working directoy before vs accesses the file. So, with a long path, relative paths cause it to create a combined path that is too long.
* VS2010: Fixed GenerateManifest flag (#10704)David Cole2011-02-091-1/+13
| | | | | | | | Thanks to "McBen <viertelvor12@gmx.net>" for the patch. (Did not preserve original commit author information because we have a push check for first and last name, and do not accept authors with only an alias...)
* VS10: Escape double quote chars in defines for rc files (#11695)David Cole2011-01-261-4/+7
| | | | | | | | To get rc defines to work in the VS10 IDE requires \" when constructing PreprocessorDefinitions strings. This is different than defines for cl. Also, per-file rc defines were not being generated. Fix that, too.
* VS10: Load projects with obj "source" files (#11147)David Cole2011-01-211-49/+54
| | | | | | | | WriteCLSources should skip source files with "obj" extensions since WriteObjSources has already written them into the vcxproj file. Likewise, WriteGroupSources should skip source files with "obj" extensions to avoid receiving "item ... already exists under the filter" project-load-time error messages from Visual Studio.
generated by cgit v0.12 at 2024-10-19 06:28:10 (GMT)