Update the CMAKE_<LANG>_LINK_EXECUTABLE rule variable to invoke the
linker directly instead of through the compiler. We already do this
for DLL linking with CMAKE_<LANG>_CREATE_SHARED_LIBRARY.
This also works around a VS 6 cl bug. While invoking the link tool
internally it fails to correctly quote flags like /pdb:... with spaces
in the value.
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.
Modern apps that use multiple threads do NOT want 10 Megabytes of RAM
per thread being used for each thread's stack... Just leave off the
/STACK: argument, and let the compiler use a reasonable default value
for the stack size.
If existing single-threaded apps require the /STACK: argument because
they do need a very large stack size, they can add the flag in their
own CMakeLists files.
From the option documentation of VS >= 7.1:
"In earlier versions of Visual C++, the compiler used several discrete
heaps, and each had a finite limit. Currently, the compiler dynamically
grows the heaps as necessary up to a total heap size limit, and requires
a fixed-size buffer only to construct precompiled headers. Consequently,
the /Zm compiler option is rarely necessary."
http://msdn.microsoft.com/en-us/library/bdscwf1c.aspx
Suggested-by: Adam Moss <adam@broadcom.com>
In the response file also linker options could be passed,
and because <OBJECTS> is replaced by a response file, it
is necessary that no compiler option follows <OBJECTS>.
This reverts commit 5598d9b2a0.
Since commit f1670ab1 (Ninja: don't confuse ninja's rsp files with
nmake's, 2012-09-26) Ninja generator response files are placed in
CMakeFiles/ so the previously existing check already avoids expanding
them.
This enables CMake to create Makefiles targeting Windows CE devices.
CMake needs to be run within a cross compile command prompt and requires
a toolchain file which sets CMAKE_SYSTEM_NAME to "WindowsCE" and
optionally CMAKE_SYSTEM_VERSION.
In commit 485a940e (VS: Simplify MSVC version reporting, 2012-08-23) we
accidentally flipped the 0/1 values of MSVC_IDE. Flip them back and
teach the CheckCompilerRelatedVariables test to check the variable.
Remove the old-style "Windows-cl.cmake" and its helper "cl.cmake". Load
the information through new-style "Platform/Windows-MSVC-<lang>.cmake"
files. Factor information common to C and CXX into a helper file
"Platform/Windows-MSVC.cmake" loaded from the per-language files.
Andreas Mohr
Brad King
Patrick Gansterer
David Cole
Peter Kümmel
Bill Hoffman