The feature needs access to all link libraries. In the future that
will only be possible to calculate at generate-time.
Even when the files were generated at configure time, they were
generated after user code in CMakeLists files were generated. No
policy is needed to handle manipulation of the files from CMake
code, because that was never possible.
Add the CMake.PolicyCheck test.
This test uses "git grep" to look for policies added in a "dated"
version of CMake. It will fail if a policy is added as of,
for example, CMake 2.8.11.20130828.
The intent is to prevent such constructs from making it into an
"official" release. Three instances actually appeared in the first
attempted release candidate for 2.8.12.
This test may sometimes yield false positives. After all, it's just
using a regular expression to detect this condition, and something
in a comment could possibly match it. As of right now, that's not
true, but it's easy to imagine such a comment being added.
The new test may also not catch all future problems of this sort.
However, it will catch problems of this sort for all code that follows
the present layout style in Source/cmPolicies.cxx.
The old version encountered a compile error on newer versions of GCC.
Update to the latest supported release of Trilinos, remove the version
number from the name of the Contract, and some other minor tweaks to
get the test passing once more.
Since commit ad502502 (cmMakefile: Track configured files so we can
regenerate them, 2013-06-18) cmMakefile::ConfigureFile records the
configured file as an output file generated by CMake. The intention is
that for make and ninja we can re-run CMake when one of the files it
generates goes missing. However, files configured temporarily in
CMakeTmp directories by Check* modules do not live past the CMake
invocation.
Teach cmMakefile::FinalPass to stop tracking files that don't
exist after we are finished generation.
When CMAKE_SUPPRESS_REGENERATION tells us not to create the ZERO_CHECK
target we should not add dependencies on it from other targets either.
Reviewed-by: Mateusz Loskot <mateusz@loskot.net>
This is necessary because custom commands and targets may create
custom files whose names are determined by generator expressions.
For example, clang should be using $<TARGET_FILE> and $<TARGET_FILE_DIR>
instead of reverse engineering the output file name:
http://thread.gmane.org/gmane.comp.compilers.clang.scm/80523
However, that can only be done when ADDITIONAL_MAKE_CLEAN_FILES
also accepts and evaluates generator expressions.
Similarly, KDE uses the LOCATION property where $<TARGET_FILE>
would also be better in KDE4_HANDLE_RPATH_FOR_EXECUTABLE but
also appends the result to ADDITIONAL_MAKE_CLEAN_FILES.
After this patch, both can be ported to generator expressions.
Commit 10a069b5 (Genex: Fix $<CONFIG> with IMPORTED targets and
multiple locations., 2013-07-15) changed the logic here to include
handling of the MAP_IMPORTED_CONFIG_<CONFIG> target property, but
it was buggy in several ways.
Uppercase the configs in all cases, and compare the mapped configs
with the parameter to the CONFIG genex, instead of with the key of
the mapping.
Ensure CMAKE_DATA_DIR, CMAKE_DOC_DIR, and CMAKE_MAN_DIR are always
relative paths in CMake code, and set defaults accordingly. Use the
install() command instead of install_files() and install_targets().
This is more modern and also avoids stripping of the first character
from user-specified destinations.
While at it, fix the default destinations reported in the bootstrap
help.
The MSBuild version for each Visual Studio generator isn't 4.0. With
Visual Studo 2013 the ToolsVersion moved from being tied to the .NET
framework and now has its own version number.
Follow-up to commit 4a015f77 (OpenBSD: Add paths for Tcl/Tk 8.4/8.5,
2012-12-03): those paths added for OpenBSD also work on other BSDs, some
of which are already using version 8.6 of Tcl/Tk.
Stephen Kelly
Kitware Robot
Rolf Eike Beer
Robert Maynard
Brad King
Zack Galbreath
David Cole
Raphael Kubo da Costa