81ecc726 FindCUDA: Added some additional comments about non-existent dependency files.
4b561b4c FindCUDA: Fix for when a non-existent dependency file is found.
Implementation indicates that at least two components of VERSION must
be specified (see Source/cmCMakeMinimumRequired.cxx.) Therefore the
minor version is not optional.
The COMPATIBLE_INTERFACE_NUMBER_MAX example now sets
INTERFACE_CONTAINER_SIZE_REQUIRED on lib1Version2 and lib1Version3.
Previously set it on lib1Version2 twice and never on lib1Version3.
Previously if a non-existent dependency file is found we set the file to "" and
then do if(NOT IS_DIRECTORY "${file}"). Later we call get_filename_component
on the empty file which returns basically the current build directory.
Having a dependency on the current build directory is really annoying, because
anything that compiles into that directory will change the file stamp and
cause your files to rebuild every time you call make. :(
Since commit v3.5.0-rc1~32^2~1 (ExternalProject: Simplify `cmake
--build` configuration passing, 2016-01-19) we use the `$<CONFIG>`
generator expression to generate the `cmake --build . --config <config>`
value for the default BUILD_COMMAND instead of the CMAKE_CFG_INTDIR
placeholder value provided by multi-config generators. However, some
projects have been abusing the old implementation detail by setting
CMAKE_CFG_INTDIR themselves to get a specific configuration. Those
projects should be updated to set their own BUILD_COMMAND to get
non-default behavior. Meanwhile we can be compatible with their
existing releases by detecting when CMAKE_CFG_INTDIR is not a
generator-provided placeholder and using its value instead.
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.
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>
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>
