summaryrefslogtreecommitdiffstats
path: root/Source/cmLocalVisualStudio7Generator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* Port all cmOStringStream to std::ostringstream.Stephen Kelly2015-01-111-2/+2
| | | | All compilers hosting CMake support the std class.
* Fix incremental linking setting for Fortran + VSZack Galbreath2014-11-211-2/+16
| | | | | | | | | | | | | | This commit fixes a bug where it was impossible to specify /INCREMENTAL to Fortran projects built with Visual Studio. The problem was due to the fact that .vfproj files expect the value of this flag to be "linkIncremental{No,Yes}, whereas .vcproj files expect this value to be 0, 1, or 2. The implementation of this fix adds a new data structure for Visual Studio linker flags specific to Fortran. This can easily be extended in the future if more such discrepencies between C/C++ and Fortran linking are discovered.
* VS: Support Intel Fortran 15 .vfproj generation (#15175)Brad King2014-09-301-0/+14
| | | | | | | | | | | | | | | | This version of the Intel Fortran plugin to Visual Studio says: please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile) We must set TargetName and TargetExt in addition to the existing setting for OutputDirectory. The settings do not appear to hurt older versions of Intel Fortran, so set them unconditionally. Extend the FortranOnly test to cover a corresponding use case by using the OUTPUT_NAME target property. Inspired-by: Ian Harvey <Ian.Harvey@megms.com.au>
* VS: Add MASM support to VS 8 and 9 (#8170, #14984)Brad King2014-08-201-0/+51
|
* cmLocalVisualStudio7Generator: Rename local 'lang' varBrad King2014-08-131-3/+3
| | | | | In the WriteGroup method, rename the 'lang' var to 'ppLang' since it is specifically for the preprocessor definitions language selection.
* VS: Encode mapped flag values in XML project files (#15031)Brad King2014-07-231-1/+1
| | | | | | | Teach cmVisualStudioGeneratorOptions to encode FlagMap entries and the FlagString value properly in vcproj/vcxproj XML files. Update the one existing call site that pre-encoded the value to not do so.
* VS: Delay getting platform name in local generatorBrad King2014-07-171-8/+16
| | | | | | Ask the global generator during generation instead of trying to store it up front. Later the global generator may not know the platform name when it is creating the local generator.
* Merge topic 'vs-vcproj-bool-case'Brad King2014-05-291-28/+28
|\ | | | | | | | | b684ce58 VS: Use lower-case boolean values in VS 7-9 (#14927)
| * VS: Use lower-case boolean values in VS 7-9 (#14927)Mark Salisbury2014-05-281-28/+28
| | | | | | | | | | | | | | The VS 7-9 IDEs parse .vcproj file boolean values in lower or upper case. The .NET XML parsing chokes on anything but "true", "false", "0", "1". Teach our generators to use lower-case names since they will work for both parsers. Our VS >= 10 flag tables already use lower-case.
* | cmTarget: Make the source files depend on the config.Stephen Kelly2014-04-021-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2/+2
| | | | | | | | | | Continue to call GetOrCreateSource where necessary to create cmSourceFile objects which have the GENERATED attribute set.
* | Encoding: If configured, write Visual Studio project files as UTF-8.Clinton Stimpson2014-03-141-4/+8
| |
* | Generalize cmCustomCommandGenerator to more fieldsBrad King2014-03-121-11/+13
| | | | | | | | | | | | | | 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.
* | stringapi: Use strings for dependency informationBen Boeckel2014-03-081-1/+1
| |
* | stringapi: Miscellaneous char* parametersBen Boeckel2014-03-081-4/+4
| |
* | stringapi: Pass configuration names as stringsBen Boeckel2014-03-081-7/+9
| |
* | 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.
* | stringapi: Take strings in escaping functionsBen Boeckel2014-03-081-2/+2
| |
* | stringapi: Use strings for VS project namesBen Boeckel2014-03-081-3/+2
| |
* | stringapi: Use strings in target nameBen Boeckel2014-03-081-15/+15
| |
* | stringapi: Use strings for the languagesBen Boeckel2014-03-081-16/+16
| |
* | VS: For Intel Fortran .vfproj put OBJECT libs in link line (#14777)Brad King2014-02-271-4/+4
| | | | | | | | | | | | | | | | | | The Intel Fortran .vfproj format accepts the $(Configuration) placeholder in the path to an input file but appears to consider it always out of date. Therefore adding OBJECT library objects as external object source files causes the referencing binary to re-link on every build. Work around this problem by putting OBJECT library objects on the link line as is done for VS < 8 already.
* | MSVC: Add properties to configure compiler PDB files (#14762)Brad King2014-02-261-1/+12
|/ | | | | | | | | | Since commit v2.8.12~437^2~2 (VS: Separate compiler and linker PDB files 2013-04-05) we no longer set /Fd with the PDB_NAME or PDB_OUTPUT_DIRECTORY properties. Those properties now exclusively handle linker PDB files. Since STATIC libraries do not link their compiler PDB file becomes more important. Add new target properties "COMPILE_PDB_NAME[_<CONFIG>]" and "COMPILE_PDB_OUTPUT_DIRECTORY[_<CONFIG>]" to specify the compiler PDB file location and pass the value to the MSVC /Fd option.
* 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-3/+3
| | | | | Also use SystemTools::Fopen() instead of fopen(). This is to eventually support utf-8 filenames.
* Windows: Use wide-character system APIsClinton Stimpson2013-12-091-1/+1
| | | | | Make CMake compile with -DUNICODE. Make it possible for the 8 bit encoding to eventually be UTF-8 instead ANSI.
* Merge topic 'vs9-map-Fd'Brad King2013-11-201-0/+2
|\ | | | | | | | | bf1db49 VS: Map /Fd to ProgramDataBaseFileName for VS 7,8,9 (#14577)
| * VS: Map /Fd to ProgramDataBaseFileName for VS 7,8,9 (#14577)Brad King2013-11-181-0/+2
| | | | | | | | | | | | | | | | Since commit 42ba1b08 (VS: Separate compiler and linker PDB files, 2013-04-05) the VS generators no longer add ProgramDataBaseFileName. Therefore we should allow projects to do so by mapping the /Fd option. For VS >= 10 our flag tables map /Fd to ProgramDataBaseFileName already. Add the mapping for VS 7, 8, and 9.
* | VS: Set .NET target framework version for VS 7-9 (#14499)Brad King2013-10-211-0/+5
| | | | | | | | | | | | | | | | | | | | | | Teach the VS 7-9 generators to honor the VS_DOTNET_TARGET_FRAMEWORK_VERSION target property. This was already done for VS >= 10 by commit cfe6300a (VS: Add support for .NET target framework version, 2013-06-14). Inspired-by: mar.na@t-online.de
* | VS: Expose Intel Fortran .vfproj format version to CMake languageBrad King2013-10-181-29/+1
| | | | | | | | | | | | Lookup the Intel VS plugin version on demand in the VS global generator, compute the corresponding .vfproj format version number, and memoize it. Add it as a CMAKE_VS_INTEL_Fortran_PROJECT_VERSION platform definition.
* | Add the INTERFACE_LIBRARY target type.Stephen Kelly2013-10-071-1/+11
|/ | | | | | | | | | | | | | | | | | | | | | | | | | 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: Future-proof Intel project format selectionBrad King2013-09-101-7/+11
| | | | | | | | The version of Intel Fortran that actually uses 9.10 as a project format is very old. Default to the latest format version (11.0) and use the older format only when known to be necessary. Suggested-by: Dick Munroe <munroe@csworks.com>
* Merge topic 'optimize-custom-command-dependencies'Brad King2013-08-071-4/+3
|\ | | | | | | | | | | 2268c41 Optimize custom command full-path dependency lookup eccb39d VS 6,7: Refactor local generators to avoid GetSourceFileWithOutput
| * VS 6,7: Refactor local generators to avoid GetSourceFileWithOutputBrad King2013-08-061-4/+3
| | | | | | | | | | | | Use the cmSourceFile returned by AddCustomCommandToOutput instead of throwing out the return value and looking it up with GetSourceFileWithOutput.
* | Fix setting of the entry point symbol for Windows CE (#14088)Patrick Gansterer2013-08-051-9/+12
|/ | | | | Set the EntryPointSymbol only when it has not been set before and use the correct symbol depending on the usage of Unicode.
* Unify the way the flags of a static library are readPatrick Gansterer2013-07-311-11/+1
| | | | | Introduce cmLocalGenerator::GetStaticLibraryFlags() to have a central function for getting the linker flags for a given target.
* Refactor cmTarget::GetCompileDefinitions to use an out-vector, not a string.Stephen Kelly2013-07-111-1/+3
| | | | Refactor to create AddCompileDefinitions.
* Refactor target COMPILE_OPTIONS and COMPILE_FLAGS handlingBrad King2013-06-271-9/+3
| | | | | | | | | | | | 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-1/+1
|
* Add cmLocalGenerator::GetCompileOptions.Stephen Kelly2013-06-021-1/+3
| | | | | | 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.
* VS: Allow /Fa to set AssemblerListingLocation (#14153)Brad King2013-05-201-1/+5
| | | | | | | | | | Generate the default AssemblerListingLocation through the flag map so that it can be overridden by a user /Fa flag. Also teach the VS 7-9 generators to map /Fa to AssemblerListingLocation. While at it, fix the AssemblerListingLocation default value to have a trailing slash after the configuration name. This ensures it will be treated as a directory and not a file name.
* Merge topic 'doc-improvements'Brad King2013-05-161-7/+7
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
| * Fix spelling and typos (affecting users)Andreas Mohr2013-05-071-7/+7
| |
* | VS: Separate compiler and linker PDB files (#11899, #14062)Brad King2013-04-051-10/+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-1/+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: Avoid empty source groups in some cases (#3474)Anton Helwart2013-03-081-7/+21
| | | | | | Teach the WriteGroup method return true if a group or any of its children have source files. Have children write their output to a temporay cmOStringStream. Add it to the real output only if not empty.
* VS: Specify WinCE subsystems correctly in VS 9 2008Mark Salisbury2013-02-131-3/+17
|
generated by cgit v0.12 at 2024-09-01 04:08:44 (GMT)