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>
Otherwise, CTEST_USE_LAUNCHERS can be set to true in a driving ctest
script, and everything looks like it would work and reports 0 build errors,
but actually there can be any amount of errors and they are just not reported.
By adding this check cmake now errors out if CTEST_USE_LAUNCHERS is enabled, but
the RULE properties are not set, which would lead to a not-working ctest run.
Alex
There is no need to do so. Be consistent with include directories and
ensure uniqueness.
This requires changing the API of the cmLocalGenerator::AppendDefines
method, and changing the generators to match.
The test unfortunately can't test for uniqueness, but it at least verifies
that nothing gets lost.
a3815e6 -fix line length
9110d0e Eclipse on OSX: improve handling of framework include dirs (#13367)
d97b385 Eclipse on OSX: fix handling of framework include dirs (#13464)
If the depender (e.g. foo.o) does not exist, also rescan dependencies if
one of the dependees (e.g. foo.cxx) is older than the already existing
depend.internal file, since this means it can be out of date.
Alex
directory where the project file is located (${CMAKE_BINARY_DIR}), which can
happen e.g. for EXECUTABLE_OUTPUT_PATH and related variables.
Now, it seems this code never worked.
If EXECUTABLE_OUTPUT_PATH was set to point into a subdir of CMAKE_BINARY_DIR,
the code did nothing.
If it pointed directly at CMAKE_BINARY_DIR or some other location, it created
a linked resource. I tested this with Eclipse Europa (3.3) and Juno (4.2), and in this
case both versions of Eclipse complained that this is a bad location for a linked resource.
Alex
It seems that if cmake finds something like the following:
/System/Library/Frameworks/GLUT.framework/Headers
Eclipse doesn't like that and wants to have
/System/Library/Frameworks
instead
Alex
...comparison operator in the IF command. In the event of
a tie, we intentionally return "true" so that dependent
build operations are guaranteed to occur until one file
is definitively newer than the other file.
A tie means we're not sure, so return true to be on the
safe side.
SORT, REVERSE, and REMOVE_DUPLICATES can only operate on exactly one argument.
Until now all other arguments were silently ignored. Give an error instead.
This expression evaluates to '1' or '0' to indicate whether the build
configuration for which the expression is evaluated matches tha named
configuration. In combination with the "$<0:...>" and "$<1:...>"
expressions this allows per-configuration content to be generated.
Add generator expressions that combine and use boolean test results:
$<0:...> = empty string (ignores "...")
$<1:...> = content of "..."
$<AND:?[,?]...> = '1' if all '?' are '1', else '0'
$<OR:?[,?]...> = '0' if all '?' are '0', else '1'
$<NOT:?> = '0' if '?' is '1', else '1'
These will be useful to evaluate (future) boolean query expressions and
condition content on the results. Include tests and documentation.
Since commit 77543bde (Convert CMake-language commands to lower case,
2012-08-13) the CMakeVersion.cmake file contains lower-case 'set'
commands. Teach CMakeVersion.bash to replace the lower-case name
instead of the old upper-case 'SET'.
Ancient versions of CMake required else(), endif(), and similar block
termination commands to have arguments matching the command starting the
block. This is no longer the preferred style.
Run the following shell code:
for c in else endif endforeach endfunction endmacro endwhile; do
echo 's/\b'"$c"'\(\s*\)(.\+)/'"$c"'\1()/'
done >convert.sed &&
git ls-files -z -- bootstrap '*.cmake' '*.cmake.in' '*CMakeLists.txt' |
egrep -z -v '^(Utilities/cm|Source/kwsys/)' |
egrep -z -v 'Tests/CMakeTests/While-Endwhile-' |
xargs -0 sed -i -f convert.sed &&
rm convert.sed