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
