summaryrefslogtreecommitdiffstats
path: root/Source/cmLocalVisualStudio7Generator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* Merge topic 'remove-CMAKE_USE_RELATIVE_PATHS'Brad King2015-06-041-8/+5
|\ | | | | | | | | | | | | | | 6e570f85 cmLocalGenerator: Remove 'optional' parameter from Convert. 3d8c6cd9 cmLocalGenerator: Remove obsolete method. e44e6bcc Port away from obsolete method. 1335992c Remove CMAKE_USE_RELATIVE_PATHS variable.
| * cmLocalGenerator: Remove 'optional' parameter from Convert.Stephen Kelly2015-06-041-5/+2
| | | | | | | | Port callers away from it.
| * Port away from obsolete method.Stephen Kelly2015-06-031-3/+3
| |
* | VS: Compute project GUIDs deterministicallyBrad King2015-06-041-10/+1
|/ | | | | | | | | Compute deterministic GUIDs that are unique to the build tree by hashing the path to the build tree with the GUID logical name. Avoid storing them in the cache, but honor any found there. This will allow project GUIDs to be reproduced in a fresh build tree so long as its path is the same as the original, which may be useful for incremental builds.
* cmLocalGenerator: Require a valid cmState::Snapshot in the ctor.Stephen Kelly2015-05-271-2/+3
| | | | | | | | | | | Refactor the local generator creation API to accept a cmState::Snapshot. Adjust MakeLocalGenerator to use the 'current' snapshot in cases where there is no parent. Create the snapshot for subdirectories in cmMakefile::AddSubdirectory. This means that snapshots are now created at the point of extending the tree, as appropriate, and independently of the cmLocalGenerator and cmMakefile they represent the state for.
* VS: Do not accumulate configurations globally (#15577)Brad King2015-05-211-30/+24
| | | | | | | | | | | Drop the VS >= 7 generator's global Configurations member and instead lookup configurations using cmMakefile::GetConfigurations where needed. This avoids accumulating all CMAKE_CONFIGURATION_TYPES values ever encountered by a project() or enable_language() command and allows the final value to be used in each directory. We don't officially support per-directory CMAKE_CONFIGURATION_TYPES values but we certainly should not generate configurations not in the final value in the top level directory.
* Use cmSystemTools::GetCMakeCommand() to get path to cmake internallyBrad King2015-05-201-3/+1
| | | | | This is much simpler than finding a way to lookup "CMAKE_COMMAND" everywhere.
* VS: Move version information to global generator.Stephen Kelly2015-05-191-22/+25
|
* VS: Simplify setting of flag table.Stephen Kelly2015-05-191-3/+2
|
* cmLocalGenerator: Require a global generator in the constructor.Stephen Kelly2015-05-141-2/+3
| | | | Port generator factory methods to pass it.
* cmLocalGenerator: Require a parent in the constructor.Stephen Kelly2015-04-281-2/+3
| | | | | | | Pass the parent though cmGlobalGenerator::CreateLocalGenerator. This will make it easy to initialize state scopes independent of cmMakefile.
* cmMakefile: Port users of GetStart* methods to new names.Stephen Kelly2015-04-201-7/+7
|
* cmMakefile: Rename GetCurrent{Output,Binary}Directory.Stephen Kelly2015-04-201-2/+2
| | | | Match names used in CMake code.
* cmState: Move CacheEntryType enum from cmCacheManager.Stephen Kelly2015-04-131-2/+1
|
* Merge topic 'vs-Intel-Fortran-map-more-flags'Brad King2015-03-121-0/+7
|\ | | | | | | | | 18d5a4bc VS: Add more Fortran compiler flags to flag table (#15381)
| * VS: Add more Fortran compiler flags to flag table (#15381)Oyvind Jensen2015-03-101-0/+7
| | | | | | | | | | | | Due to a difference in how AdditionalOptions are implemented in the Fortran component of VS and the C/C++ component, flags that are not listed in the flag table are at risk of being overwritten.
* | Genex: Allow COMPILE_LANGUAGE when processing compile definitions.Stephen Kelly2015-03-091-1/+1
|/ | | | Issue an error if this is encountered by an IDE generator.
* VS: Fix .vcproj and .vfproj file OutputDirectory generationBrad King2015-02-161-2/+11
| | | | | | | | | | | | | | | | | | | | | | Teach cmLocalVisualStudio7Generator to set 'OutputDirectory' using the same method as is used to set the 'OutputFile' in the generated project file. Also, OutputDirectory only needs to be set for targets that run the linker or librarian. These two changes make the VS 7 OutputDirectory consistent with what cmVisualStudio10TargetGenerator generates for OutDir. Without this, since the VS Intel Fortran plugin for VS >= 10 still uses the VS 7 .vfproj file format, when executing test VSGNUFortran using Intel Fortran Compiler 15.xx, the following warning is issued just before compilation: TargetPath(...) does not match the Linker's OutputFile property value (...). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile). Subsequently, an error is reported during linking. Inspired-by: Vincent Newsum <vynewsum@gmail.com>
* VS: Use $(ConfigurationName) as CMAKE_CFG_INTDIR in VS 7, 8, 9Brad King2015-02-161-1/+2
| | | | | | | | | This will allow us to use a value other than just the config name for the project OutputDirectory setting used for $(OutDir). Also use $(ConfigurationName) instead of $(OutDir) for the link directory configuration suffix since that is a hard-coded instance of a use case for CMAKE_CFG_INTDIR.
* 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.
generated by cgit v0.12 at 2025-01-07 21:10:28 (GMT)