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.
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.
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.
Similar incomplete generator expressions are already tested
in the GeneratorExpression unit test, but those are executed
with add_custom_target. The generator expressions in the include
directories are run through the preprocessor, whereas the ones
run through add_custom_target are not.
In commit 2a797539 (FindPNG: improve library detection, 2013-07-27) we
split the search for PNG into separate PNG_LIBRARY_DEBUG and
PNG_LIBRARY_RELEASE variables. However, if a project or user sets the
old PNG_LIBRARY value we must honor it instead of searching.
While at it, mark PNG_LIBRARY_RELEASE and PNG_LIBRARY_DEBUG as advanced
and remove a stray debug message.
CMake's intended interface for linking to explicit object files (marked
with EXTERNAL_OBJECT) is that only those listed as target sources should
be linked. Drop FindCUDA's attempt to hide the .obj files from VS IDE
project files, which depends on VS-version-specific behavior of linking
custom command outputs that happen to be named "*.obj". CMake puts
external object files in a dedicated source group anyway.
The workaround currently present works fine without -O or with -O1, but fails
with -Os or -O2 and higher. Using -O2 is common e.g. in Gentoo, as resulting in
bugs like this:
https://bugs.gentoo.org/473276
Prevent the workaround for higher optimization levels to make bootstrapping
more likely to succeed.
This is still a workaround as ld still keeps crashing in some situations.
In commit fb9f73de (MSVC: Invoke 'link' directly for executables,
2013-04-08) we forgot to remove the /link option handling added by
commit e31df039 (Ninja: move <OBJECTS> in front of the first linker
option, 2012-09-27) to the Platform/Windows-MSVC module. Drop it now.
Kitware Robot
Brad King
Patrick Gansterer
Stephen Kelly
Rolf Eike Beer