The POSITION_INDEPENDENT_CODE property documentation states that its
default value depends on whether SHARED or MODULE is given to the
add_library call. Since these are options to the add_library command we
should document on the command how they affect the property.
While at it, add a missing space to the POSITION_INDEPENDENT_CODE
property documentation.
32b7c72 Merge branch 'cmake-platform-info-version' into msvc-compiler-info
f3ddfef Modernize MSVC compiler information files
485a940 VS: Simplify MSVC version reporting
32db033 VS: Remove support for "free" version 2003 tools
e5fee8a Store ABI detection results in compiler information files
3df81b4 Move CMAKE_<LANG>_COMPILER_WORKS to compiler information files
7195aca Make platform information files specific to the CMake version
Teach Windows-cl.cmake to use CMAKE_(C|CXX)_COMPILER_VERSION to set the
"MSVC##" and MSVC_VERSION variables. It no longer needs the IDE generator
to dictate the version or to detect the version by running the
command-line tool for NMake and Ninja generators. Drop configuration of
CMakeCPlatform.cmake and CMakeCXXPlatform.cmake from Windows-cl.cmake.in
because all the results it saved are now cheap to compute every time.
Until now it was only rerun if the compile definitions changed, but
of course it also has to rerun if the include dirs or moc options
change. Strange that I didn't notice this before...
Alex
403ead6 Document CMAKE_<LANG>_COMPILER_(ID|VERSION) values
8be51f6 Test variables CMAKE_(C|CXX|Fortran)_COMPILER(|_ID|_VERSION)
ec22a9b Cleanly enable a language in multiple subdirectories
66cb335 VS: Detect the compiler id and tool location
89595d6 VS10: Define CMAKE_VS_PLATFORM_TOOLSET variable
965a69d Xcode: Detect the compiler id and tool location
9a9e1ee CMakeDetermineCompilerId: Prepare to detect IDE compiler id
b8b5c83 Re-order C/C++/Fortran compiler determination logic
709fa59 Ninja: remove GetTargetPDB because it is used only once
4bb4787 Ninja:split out setting of msvc TARGET_PDB
59cbc28 Ninja: prepare msvc pdb cleanup
f0a1065 Rename files from main.cpp to more meaningful names.
ca7fb14 Fix the test setting COMPILE_DEFINITIONS target property
733deb6 Fix CompileDefinitions test on Visual Studio.
3dae652 Don't duplicate -D defines sent to the compiler.
ee949d8 Remove duplicate 'of' from docs.
ecc1acb Remove incorrect doc string for link type enum
805f5e5 Fix some typos in the docs.
389d423 Add missing whitespace to docs.
8aed02a -fix Java dependency scanning, broken in previous commit
7ae4479 -fix line length
87fe428fix#13474: also rescan dependencies if the depender does not exist
At the top of a build tree we configure inside the CMakeFiles directory
files such as "CMakeSystem.cmake" and "CMake<lang>Compiler.cmake" to
save information detected about the system and compilers in use. The
method of detection and the exact results store varies across CMake
versions as things improve. This leads to problems when loading files
configured by a different version of CMake. Previously we ignored such
existing files only if the major.minor part of the CMake version
component changed, and depended on the CMakeCache.txt to tell us the
last version of CMake that wrote the files. This led to problems if the
user deletes the CMakeCache.txt or we add required information to the
files in a patch-level release of CMake (still a "feature point" release
by modern CMake versioning convention).
Ensure that we always have version-consistent platform information files
by storing them in a subdirectory named with the CMake version. Every
version of CMake will do its own system and compiler identification
checks even when a build tree has already been configured by another
version of CMake. Stored results will not clobber those from other
versions of CMake which may be run again on the same tree in the future.
Loaded results will match what the system and language modules expect.
Rename the undocumented variable CMAKE_PLATFORM_ROOT_BIN to
CMAKE_PLATFORM_INFO_DIR to clarify its purpose. The new variable points
at the version-specific directory while the old variable did not.
Several more recent Visual Studio Express editions are now available and
they support debug builds. Simplify our VS platform files by removing
support for these old tools. If anyone still uses them we can restore
support with a more modern way to test for them.
When a language is not enabled at the top level of a project but is
enabled in multiple disjoint subdirectories we should re-use the
CMake<lang>Compiler.cmake file from the first directory. Load the file
whenever it exists and is not left from a different version of CMake.
Run cmparseMSBuildXML.py on cl.xml, lib.xml, and link.xml to generate
our flag tables:
python cmparseMSBuildXML.py -x ".../MSBuild/Microsoft.Cpp/v4.0/V110/1033/cl.xml" > cmVS11CLFlagTable.h
python cmparseMSBuildXML.py -x ".../MSBuild/Microsoft.Cpp/v4.0/V110/1033/lib.xml" > cmVS11LibFlagTable.h
python cmparseMSBuildXML.py -x ".../MSBuild/Microsoft.Cpp/v4.0/V110/1033/link.xml" > cmVS11LinkFlagTable.h
Fix up the declaration names at the top of each file. Finally, teach
cmVisualStudio10TargetGenerator to select the version of the table
matching the version of VS.
In VS 11 the WindowsAppContainer element enabled by the
VS_WINRT_EXTENSIONS property activates precompiled header support
automatically if no PrecompiledHeader setting is specified. For VS 10 and
11 set PrecompiledHeader to "NotUsing" explicitly by default unless
overridden by a project-specified flag.
Suggested-by: Eugene Golushkov <eugene_gff@ukr.net>
Since commit 9e01aefd (VS: Add support for WinRT project properties,
2012-02-03) CMake generates for VS 11 projects the 'Immersive' element
for the VS_WINRT_EXTENSIONS target property. That was based on the VS
11 preview version. The final version renamed the element to
'WindowsAppContainer', so generate that instead.
Suggested-by: Eugene Golushkov <eugene_gff@ukr.net>
Kitware Robot
David Cole
Brad King
Stephen Kelly
Alex Neundorf
Patrick Gansterer
Zack Galbreath
Peter Kümmel