Move the cmake::ExecuteCMakeCommand static method and all the static
methods it calls out of the 'cmake' class to a separate 'cmcmd' class.
Build the latter as part of the main cmake executable with cmakemain.cxx
and not in CMakeLib. Drop unused header includes from "cmake.cxx".
By moving this implementation out of cmake.cxx we avoid carrying it
around in all the executables that use class 'cmake'. It is needed only
for the main "cmake -E" functionality.
The lack of Qt4 on a system should silently skip the corresponding tests
with no other messages. This is already the case for other find_package
calls in Tests/CMakeLists.txt.
Xcode 2.1 through 4 supported $(CURRENT_ARCH) in a PBXFileReference
'path' value used in the "Link Binary with Libraries" build phase.
CMake uses this to reference object file locations on link lines to
bring in OBJECT library content. However, Xcode 5 now evaluates the
$(CURRENT_ARCH) reference in this context as "undefined_arch" so the
wrong path is given to the linker. There seems to be no alternative way
to produce an architecture-specific value in a PBXFileReference.
Fortunately Xcode 5 now also handles link dependencies for paths linked
through OTHER_LDFLAGS. For Xcode >= 5, move the OBJECT library object
file references from the link build phase to OTHER_LDFLAGS. We can
still show the object files in the source group listing in either case.
Xcode 5.0 now computes dependencies from files linked through
OTHER_LDFLAGS, so we no longer need the XCODE_DEPEND_HELPER hack to
re-link dependents when targets change.
Xcode 5.0 now relinks targets when their shared libraries dependencies
are modified, and there seems to be no way to stop it. Report this as a
known limitation in the test output and do not fail.
In Tests/Architecture and Tests/BuildDepends/Project we select a set of
OS X cpu architectures to use for the test. Prior to Xcode 4 we always
used i386 and ppc. Starting with Xcode 4, the tools do not support ppc
but do support x86_64, so we switch to that. Fix the version check to
recognize Xcode >= 5 as at least Xcode 4 and use the new architectures.
In buggy code like
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/out.h
MAIN_DEPENDENCY ${CMAKE_CURRENT_SOURCE_DIR}/out.h.in
...)
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/out.h
...)
that has more than one rule to generate the same output CMake has always
used the first rule. However, since commit 2268c41a (Optimize custom
command full-path dependency lookup, 2013-08-06) we update the map from
output to cmSourceFile for every rule generating an output, effectively
keeping the last command instead of the first.
Fix this regression by checking for each map update if the output
already has an entry. If so, keep only the original entry. The VS 8
generator triggers this with a special case for generate.stamp rules
that differ between ZERO_CHECK and normal targets, so do not warn for
now. Leave a TODO comment for warning in the future.
In Modules/Platform/Darwin.cmake set CMAKE_SYSTEM_FRAMEWORK_PATH to
include framework directories from inside the system SDK corresponding
to CMAKE_OSX_SYSROOT.
Suggested-by: Sean McBride <sean@rogue-research.com>
A future version of CMake may not print the "cmake version" line at the
beginning of the --help-*-list output. Filter out the line with 'grep'
instead of 'tail' to tolerate output from versions of CMake with and
without the version line. Match "cmake version", "cpack version", and
"ctest version" in each corresponding completion script.
The subsystem must be set to WINDWOSCE for some SDKs to link an
executable. Set it to 9 for VS2005 and to 8 for VS2008, since the
value differs between the different Visual Studio versions.
In commit bd827f98 (Use COFF file header header for architecture
detection, 2013-08-05) the MSVC_<lang>_ARCHITECTURE_ID value computed by
CMakeDetermineCompilerId.cmake changed for WinCE architectures to be the
exact architecture read from the PE header. Fix platform preprocessor
definitions in Modules/Platform/Windows-MSVC.cmake to correspond to the
architecture family (ARM or SHx) instead of the specific architecture.
Multiple libraries in a single buildsystem can be exported to multiple
export-sets.
If a library from one export set depends on a library from
another export set, the export logic generates a check in the targets
file to verify that the target in the other export set is found. That
check is executed at downstream-find_package-time.
However, a target may depend privately on a target in another export
set. In that case, the depend used to also be listed in the required
targets in the targets file. Change the export logic to ignore the
private link entries instead.
In commit 8fcf0ab0 (Add support for new Windows CE compiler, 2013-08-04)
we made corelibc conditional on the MSVC version, but the version value
was incorrect. Update it to use corelibc for VS 2008 and below.
Resolve conflict in Source/cmTestGenerator.cxx by taking "their" side
(test-property-genex). It already accounts for the lower-case change in
"our" side (generate-modern-style).
The old-style add_test() call does not support generator expressions at
all. This also applies to the properties for the test, but it is not
mentioned at all.
This is useful for cases like:
add_test(NAME mytest COMMAND mydriver $<TARGET_FILE:myexe>)
set_tests_properties(mytest PROPERTIES
REQUIRED_FILES "$<TARGET_FILE:myexe>"
WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/$<CONFIGURATION>"
)
In this example we require the actual test executable to exist to
run the test in addition to the test driver at argv[0]. Also the
$<CONFIGURATION> expression improves over \${CTEST_CONFIGURATION_TYPE}
because the latter is not normalized for case-sensitive filesystems.
Move property generation from GenerateScriptConfigs to separate copies
in GenerateOldStyle and GenerateScriptForConfig. This causes the
per-config tests generated for the add_test(NAME) signature to each get
their own test properties. This will allow us to later change the
property values based on the test configuration.
While at it, generate lower-case CMake code (e.g. set_tests_properties).
Inspired-by: Ben Boeckel <mathstuf@gmail.com>
State explicitly that the dependencies will build before the target.
Drop wording that may imply the opposite.
Suggested-by: Rob Stewart <robert.stewart@sig.com>
When FindHDF5 was first added in commit e6734068 (Add HDF5 find
module..., 2009-08-24) it contained a workaround for a bug in
SelectLibraryConfigurations that did not transform lists correctly.
That bug was fixed by commit 5797512c (SelectLibraryConfiguration:
generate correct output when input vars are lists, 2012-07-28). Then
refactoring in commit 04d4dc33 (SelectLibraryConfigurations: Use
-NOTFOUND instead of copying the vars, 2013-07-08) changed undocumented
behavior on which the original workaround relied. The result puts
entries like HDF5_hdf5_LIBRARY_DEBUG-NOTFOUND in HDF5_LIBRARIES.
Fix this by dropping the original workaround since the underlying issue
has been fixed anyway. Use the HDF5_${LIB}_LIBRARY selected by the call
to select_library_configurations directly.
Kitware Robot
Brad King
Patrick Gansterer
Stephen Kelly
Eric NOULARD
Simon Levermann
Ben Boeckel