Previously we did not clearly document that `--target` is only supported
to be specified once. Even worse, specifying it multiple times would
silently ignore any previously specified targets and only build the last
target.
Update the documentation to specify this. Update the implementation to
reject multiple `--target` options to prevent user errors.
Updates to Tests/Fortran by commit v3.2.0-rc1~501^2 (Avoid if() quoted
auto-dereference, 2014-10-14) changed our check
"${CMAKE_Fortran_COMPILER_ID}" MATCHES "${CMAKE_C_COMPILER_ID}"
to
CMAKE_Fortran_COMPILER_ID MATCHES CMAKE_C_COMPILER_ID
because CMP0054 warned about the LHS compiler id "MSVC" being expanded.
However, the RHS of if(MATCHES) does not auto-dereference so this check
has returned FALSE since then and the FortranCInterface part of the test
has not been running!
Fix this by using STREQUAL with quoted arguments and setting CMP0054 to
NEW (by requiring 3.1).
Refactoring merged by commit v3.5.0-rc1~299 (Merge topic
'use-generator-target', 2015-10-20) in and around
commit v3.5.0-rc1~299^2~13 (cmExportSet: Store a cmGeneratorTarget,
2015-10-17) changed export sets to delay looking up actual targets and
stores only their names. However, in InstallCommand::HandleExportMode
we need to lookup targets immediately to check them for
EXPORT_LINK_INTERFACE_LIBRARIES. The check was accidentally made local
to the current directory, so if an export set contains a target from
another directory the lookup fails and CMake crashes. Fix the check to
look up the target name globally, and tolerate when no target is found
just in case.
Reported-by: Kelly Thompson <kgt@lanl.gov>
Refactoring in commit v3.5.0-rc1~347^2~2 (Set the current dirs on the
snapshot before creating the cmMakefile) accidentally changed the
source and binary directories configured in `cmake -E cmake_depends`
for use during dependency scanning. This can cause the wrong directory
information to be loaded. It also breaks Fortran module dependency
scanning for modules provided by targets in subdirectories that do
not have Fortran_MODULE_DIRECTORY set.
Fix the dependency scanning directory configuration and add a test to
cover the Fortran module case in which the breakage was observed.
Reported-by: Kelly Thompson <kgt@lanl.gov>
Let us take an example of a project that has some tests in a component
that need to be installed into a dedicated test package. The user
expectation is that the result could be achieved by typing the
following:
make
make tests
make install
DESTDIR=/testpkgs make install-tests
However this results in test components in the default installation as
well as the testpkg.
Add an EXCLUDE_FROM_ALL option to the install() command to tell it that
the installation rule should not be included unless its component is
explicitly specified for installation.
The dependency flags require recent versions of `iccarm` and `iccavr`.
The multi-rule dependency generated with `--dependencies=m` does not
work well with Ninja, so use `--dependencies=ns` instead.
Move all development release notes into a new version-specific document:
tail -q -n +3 Help/release/dev/* > Help/release/3.5.rst
git rm -- Help/release/dev/*
except the sample topic:
git checkout HEAD -- Help/release/dev/0-sample-topic.rst
Reference the new document from the release notes index document.
Add a title and intro sentence to the new document by hand.
While evaluating `if(MATCHES)` we get a `const char*` pointer to the
string to be matched. On code like
if(CMAKE_MATCH_COUNT MATCHES "Y")
the string to be matched may be owned by our own result variables.
We must move the value to our own buffer before clearing them.
Otherwise we risk reading freed storage.
The add_custom_command(TARGET) signature only works for targets defined
in the current directory. Clarify this in the error message when the
target exists but was defined elsewhere.
Inspired-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
Sebastian Schuberth
Brad King
Kitware Robot
Christoph Grüninger
Nick Lewis
Juhani Simola
Ashley Whetter
Prayag Verma
Bartosz Kosiorek