Extract a new method to encapsulate the requirements of evaluating
dependent-expressions, namely, propagation of the
EvaluateForBuildsystem setting, which is missing from the
getLinkedTargetsContent implementation.
Commit v3.1.0-rc1~688^2 (Genex: Only evaluate TARGET_OBJECTS to determine
target sources., 2014-03-20) introduced an error case for use of
TARGET_OBJECTS outside of the context of generating the buildsystem,
as the path to object files may be dependent on buildsystem
variables (See bug #15226).
Commit v3.1.0-rc1~314^2 (Allow INTERFACE_SOURCES to specify
$<TARGET_OBJECTS> (#14970), 2014-07-09) made it possible to
propagate such content to dependent targets.
While that commit propagated the EvaluateForBuildsystem setting
for the case of a TARGET_PROPERTY expression, as generated for
direct dependencies of a target in
cmTargetInternals::AddInterfaceEntries, it did not add propagation
for content from further transitive target dependencies, as determined
by getLinkedTargetsContent.
Now that we know the year component of this VS version we
can add it to the generator name. For convenience, map
the name without the year to the name with the year.
Visual Studio 14 (2015) complains if a static character array is
declared with more than 65535 elements. This limit should be large
enough for SharedForward clients, so just hard-code that instead of
trying to compute a limit.
CMake requires both the Desktop SDK and the correct platform SDK
(Windows Phone or Windows Store) to be installed when targeting the
Windows mobile platforms. Verify that the right platform components are
installed and give a more detailed error message when something is
wrong.
The special case added by commit v2.4.0~3051 (When building CMake
itself, use the new cmake to install so that the current cmake can be
overwritten, 2004-06-09) does not make sense when cross-compiling.
Since commit v3.1.0-rc1~227^2~1 (De-duplicate shared library targets in
generated link lines, 2014-07-30) we de-duplicate shared library targets
on the link line. However, some toolchains will fail linking if an
executable is linking to a shared library that is not used directly and
a static library that depends on the shared one. The linker may not
keep the reference to the shared library the first time and then the
symbols needed by the static library may not be found.
Fix this by reversing the direction of the for loop that removes the
duplicate shared libraries, in order to ensure that the last occurrence
of the library is left instead of the first one.
Extend Tests/Dependency with a case covering this behavior. Create an
executable that links to a shared library and a static library but only
needs the shared library as a dependency of the static library.
Co-Author: Brad King <brad.king@kitware.com>
The logic introduced in commit v3.1.0-rc1~688^2~9 (Genex: Evaluate
TARGET_OBJECTS as a normal expression, 2014-02-26) ordered a map
by pointer value and then constructed a list of object files by
iterating over the map. This is not deterministic.
Since commit v3.1.0-rc1~688^2~5 (cmTarget: Allow any generator
expression in SOURCES property, 2014-03-18) the order produced by the
above-mentioned logic started being used for the actual list of object
files on the link line. Since it is not deterministic, spurious
re-links occur after re-running CMake simply because the order of
objects changed on the link line.
Fix this by iterating over the original vector of source files instead
of the map. This has a deterministic order.
This reverts commit 5abfde6cb8.
The behaviors associated with implicit pulldown on variable lookup
seriously conflict with the optimizations made in these commits.
Basically, since values were copied upon variable lookup, not just on
PARENT_SCOPE, coupled with PARENT_SCOPE's behavior based on whether the
variable is in the current scope or not causes serious problems with not
storing a value for every variable at every scope.
The commit changed behavior of the following example, among other cases:
function(test_set)
set(blah "value2")
message("before PARENT_SCOPE blah=${blah}")
set(blah ${blah} PARENT_SCOPE)
message("after PARENT_SCOPE blah=${blah}")
endfunction()
set(blah value1)
test_set()
message("in parent scope, blah=${blah}")
Reported-by: Alex Merry <alex.merry@kde.org>
Reported-by: Ben Cooksley <bcooksley@kde.org>
Changes in commit b9aa5041 (cmLocalGenerator: Simplify GetIncludeFlags
output formatting, 2014-03-04) caused Windows Resource Compiler include
directories to be computed as relative paths in the Ninja generator.
This breaks the cmcldeps handling of include paths. The reason for the
regression is that several cmLocalGenerator::GetIncludeFlags callers
treated the fourth "bool forResponseFile" argument as if it controlled
whether include directories were a full path. It actually did control
that by accident until the above commit.
Add an explicit "bool forceFullPaths" argument to GetIncludeFlags
and thread the value through ConvertToIncludeReference as needed.
Update GetIncludeFlags call sites that really wanted to control the
forResponseFile setting to be aware of the new argument. Extend the
VSResource test to cover this case.
631fadea Help: Add notes for topic 'fix-OSX-bundle-rpaths-and-Qt5'
50e261dd OSX: Warn when attempting to change runtime paths on OS X 10.5
9b98fd52 cmake-gui: Make sure we bundle Qt5 Cocoa platform plugin
83a06bb4 BundleUtilities: Framework codesign Resources/Info.plist & Current
f7df82ac BundleUtilities: Resolve & replace @rpath placeholders
14bc686f GetPrerequisites: Make sure dyld placeholders are prefixes
6c313797 BundleUtilities: Use find on UNIX for fast executable lookup
Even though 10.5 supports @rpath, the support is not complete
enough for CMake. For instance, install_name_tool doesn't support
adding and removing rpaths.
Also modifying BundleUtilities test to remove an undesirable cmake
generated runtime path. The intent was to build with the install
rpath as is done with the other cases in this test.
e0e75a72 Help: Add notes for topic 'ctest-memcheck-sanitizers'
7345a1f7 tests: Add a test for ctest_memcheck MemorySanitizer
0c6330da ctest_memcheck: Add support for MemorySanitizer msan
9ba8bf12 tests: add a test for ctest_memcheck UndefinedBehaviorSanitizer
816c100a ctest_memcheck: Add support for UndefinedBehaviorSanitizer ubsan
b67ef537 ctest_memcheck: Order sanitizer type code consistently
f48a2968 Tests: Organize CTestTestMemcheck inner test code
Revert commit 7243c951 (Ninja: Don't limit custom cmd side-effects to
build folder, 2014-06-27) because it causes every custom command
dependency in the source tree to get a phony rule. For large projects
these rules get too big for Ninja to handle efficiently. While the
original change addressed a valid concern, it did not seem to occur
regularly in practice because well-behaved projects generate their
side-effects only in the build tree. Until we support explicit
specification of side-effects (CMake issue #14963), we will have to use
this as a middle-ground.
f25e431d tests: set sanitizer options properly
f0661bf3 tests: fix copy/paste from tsan -> asan comments
ca9cc25c ctest: add support for additional sanitizer options
0b9ffffc ctest: update documentation for CTEST_MEMORYCHECK_TYPE
Stephen Kelly
Brad King
Gilles Khouzam
Dmitry Polyanitsa
Ådne Hovda
Daniele E. Domenichelli
Clinton Stimpson
Ben Boeckel
Kitware Robot
Geoff Viola
Adam Strzelecki
Bill Hoffman
Nils Gladitz