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.
Due to #4662 -isystem support was disabled for all GNU Compilers
on Apple platforms. But the change was probably a just work around
for a broken compiler on Tiger (see 10837#c27206). So we tighten
the condition to only kick in for GCC versions earlier than 4.
That should ensure sane behavior for Xcode 3.2 and later.
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.
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.
Brad King
Horst Kronstorfer
Paul Wilkinson
Orion Poplawski
Gregor Jasny
Kitware Robot
James Bigler
Sebastian Schuberth
Christoph Grüninger
Nick Lewis
Juhani Simola
Ashley Whetter
Prayag Verma