Create target property WINDOWS_EXPORT_ALL_SYMBOLS to automatically
generate a module definition file from MS-compatible .obj files and give
it to the linker in order to export all symbols from the .dll part of a
SHARED library.
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.
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.
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.
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.
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>
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.
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.
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>
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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>
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.
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.
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.
The MS tools create two types of PDB files as explained here:
http://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.71%29.aspxhttp://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.80%29.aspxhttp://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.90%29.aspxhttp://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.
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.
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.
3a1006e VS: Added "Deploy" at project configuration for WindowsCE targets
40c36c9 VS: Make DetermineCompilerId working with WinCE too
038df9e VS: Allow setting the name of the target platform
6fe4fcb VS: Add parser for WCE.VCPlatform.config to read WinCE platforms
2118a20 VS: Support setting correct subsystem and entry point for WinCE
6920fed VS: Change variable type of Name from const char* to string
102521b VS: Change variable type of ArchitectureId from const char* to string
332dc09 VS: Add static method to get the base of the registry
d41d4d3 VS: Add CMAKE_VS_PLATFORM_NAME definition to cmMakefile
14861f8 VS: Remove TargetMachine for linker when checking compiler id
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.
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)
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>
Since commit 328c0f65 (Simplify cmVisualStudio10TargetGenerator source
classification, 2012-03-19) the VS 10 generator uses the
cmGeneratorTarget source classification instead of directly getting the
list of source files from the target. This accidentally dropped the
CMakeLists.txt files from generated projects because they are added too
late for cmGeneratorTarget.
All generator-specific source files must be added to targets prior to
cmGeneratorTarget construction. Refactor addition of the CMakeLists.txt
files with CMake re-run custom commands to take place before normal
generation begins, and therefore early enough to be included in the
cmGeneratorTarget classification.
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.
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.
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.
Stephen Kelly
Brad King
Bill Hoffman
Oyvind Jensen
Zack Galbreath
Mark Salisbury
Clinton Stimpson
Ben Boeckel
Patrick Gansterer
Andreas Mohr
Anton Helwart
Yuchen Deng
Kitware Robot
Zaheer Chothia