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.
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)
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.
Remove partial implementation added by commit ca0230a3 (check in initial
conv library stuff, 2007-02-16) since it was never finished. It does
not make sense for multi-configuration generators since no specific
build configuration is processed at CMake time.
Eliminate callers of cmMakefile::GetIncludeDirectories.
All callers of GetIncludeDirectories should go through the local generator
object.
Only the local generator calls cmTarget::GetIncludeDirectories directly.
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.
Commit 1be4b6f4 (Order VS local generator Version ivar values
consistently, 2011-11-10) fixed the Version ivar of the VS 10 local
generator by setting it correctly to 10 instead of leaving it at 7.
This broke generation of .vfproj files for the Intel Fortran plugin to
VS 10 by mixing VS 9 and 10 formats together in one file. Teach the
local generator to pretend the Version is 9 for Intel Fortran targets.
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.
As Dave Cole pointed out the previous commit only checked for 10.x and 12.x.
11.0 was accounted for, but 11.1, 11.2 and 11.3 were not. This patch
should make it work for those versions as well. I did a web check and there
are 11.0, 11.1, 11.2 and 11.3 versions from Intel. I assume if 12.x uses
11.0 as the version in the .vfproj file, then all of the 11.x versions would
as well.
The intel compiler for 12.0 and 12.1 are known to expect the file version
to be 11.0 in the .vfproj file. For 10.x it should be 9.10. Prior to
this fix 12.0 and 10.1 were the only values checked. If those did not match
the actual version of intel was put in the vfproj file causing an error
about future version load attempt in the IDE.
Define a "Fortran_FORMAT" target and source file property. Initialize
the target property from a "CMAKE_Fortran_FORMAT" variable. Interpret
values "FIXED" and "FREE" to indicate the source file format. Append
corresponding flags to the compiler command line.
920a046 QtAutomoc: Eliminate compiler warning
b00463f QtAutomoc test: Pass QT_QMAKE_EXECUTABLE
e78ce44 Fix automoc with VS builds: apply patch from Bill
71165e9 Silence warning in automoc: use long instead of int
1879bcc Fix build: use std::ios::out|ios::trunc instead of std::ios_base::out
678e124 Only enable the automoc test after checking that Qt4 works
71c29d1 Fix bootstrap test with automoc
afb3edc Fix warnings
add30e9 Fix build: non-void function must return a value
7e6d845 Automoc.cmake is not needed anymore
2963d0b Fix logic which decides when to execute automoc test
77a5c6e Add documentation for AUTOMOC, add initialization via CMAKE_AUTOMOC
bf8ef77 Add a test for automoc
d045fd4 Nicer progress message for the automoc target
50cd6ce Move automoc processing from add_executable/library to cmGlobalGenerator
cbaac2a Remove trailing whitespace
c27607b Refactor SetupAutomocTarget() so it can be run after creating the target
24d9b7d Remove trailing whitespace
58b7fe6 Use cout instead of printf()
72caf4d Add the generated automoc.cpp file to the cleaned files
ddb517d Color output when running moc
9303295 Initialize verbose based onb the env.var.
ace1215 Move code for parsing a cpp-file from the big loop to separate function
735a5bb Fix line lengths
83b730c Add AUTOMOC to the add_library() command
126c6ea Add the cmake module required currently for automoc
de91feb Remove the need to check for .h/.cxx during buildtime
d65689a Add actual automoc code from automoc
d1c0a5f Start implementing skeleton for automoc in cmake
a65011b Start work on automoc: add empty cmQtAutomoc class
Makes VS 7, 8 and 9 generators consistent with the VS 10
generator. Adds the "AdditionalIncludeDirectories" attribute
at the vcproj level so that all idl files inherit the /I
command line args.
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.
Thanks to Pau Garcia i Quiles for the inspiration for the patch.
I've tweaked it a bit compared to what's in the bug tracker: this
commit does not allow empty global variable names.
I also added usage of the new feature to an existing test. Although
it has no effect on the resulting Visual Studio projects, you can
verify that the VSResource test produces a non-empty globals section
in the generated .vcproj(x) files.
The Intel Fortran plugin forgets to create the output directory into
which it will write a DLL's import library. Utilize the fix added by
commit f4b3bdc6 (Create an exe's implib output dir for VS, 2009-06-15)
and generalized by commit 764ac980 (Generalize exe implib dir creation
for VS, 2009-06-16). Create a pre-link rule to make the directory.
Brad King
Stephen Kelly
Anton Helwart
Mark Salisbury
Patrick Gansterer
Yuchen Deng
Kitware Robot
Zaheer Chothia
David Cole
Aaron C. Meadows
Robert Dailey
Bill Hoffman
Alex Neundorf