Optionally verify that items in `LINK_LIBRARIES` and
`INTERFACE_LINK_LIBRARIES` that can be target names are actually target
names. Add a `LINK_LIBRARIES_ONLY_TARGETS` target property and
corresponding `CMAKE_LINK_LIBRARIES_ONLY_TARGETS` variable to enable
this new check.
Fixes: #22858
This was intended to be part of the initial MR (!6177), but accidentally went
missing when debugging nightly failures on less common systems. Noticed during
!6711 review as the comment about this behaviour didn't match the code.
Documentation for CMP0128 is updated to remove a false case and note the two
cases related to this.
Fixes#22224.
Due to MCST LCC compiler identification is now changed to LCC,
there should be a way for old projects to still identify it as GNU,
as it was before.
This commits adds the policy:
CMP0129: Compiler id for MCST LCC compilers is now LCC, not GNU.
This policy controls such a behavior.
OLD behaivior is to treat LCC as GNU, NEW is to treat is as LCC.
Run the script:
Utilities/Sphinx/update_versions.py --since v3.21.0 --overwrite
Manually select updates that really belong to the 3.22 release, as
against adding documentation for previously-existing entities.
The changes are part of CMP0128.
When the standard level is unset:
* Flags are added if extension mode doesn't match the compiler's default.
Previously logic only worked if LANG_EXTENSIONS was ON. Fixes#22224.
* The full flag is used. Previously CMAKE_LANG_EXTENSION_COMPILE_OPTION was
used. This was only supported for IAR.
Otherwise:
* Avoid adding flags if not necessary per the detected compiler defaults.
* Fixed check for when the requested standard is older. It now matches the
nearby comments.
I reworded the fallback comment as its logic was a bit difficult to wrap my
head around.
The OLD behavior only removes a non-cache variable of the same
name in specific circumstances. The previous wording implied
that it would always occur.
Also add a note about the behavior compared to the analogous
CMP0077 policy, which affects the option() command in a similar
but subtly different way.
The compile options `--march=<arch>` and `--mcpu=<cpu>` and the
link option `--cpu=<cpu>` are automatically added by CMake based
on `CMAKE_SYSTEM_PROCESSOR` or `CMAKE_SYSTEM_ARCH`. But this is not
sufficient, because armclang also supports enabling or disabling
features using `+<feature>`:
-mcpu=<name>[+[no]<feature>+...]
For example:
-mcpu=cortex-a57+nocrypto+nofp+nosimd+crc
(Reference: https://developer.arm.com/documentation/dui0774/k/Compiler-Command-line-Options/-mcpu?lang=en)
The problem is, even if a project adds a flag with features it needs,
CMake still adds flags, resulting in code that is compiled with wrong
CPU features and unable to run.
Add policy `CMP0123` to not automatically add compile or link options,
and let projects set them instead.
Co-Author: Brad King <brad.king@kitware.com>
Fixes: #21173
A common anti-pattern is to copy from the `CUDA_ARCHITECTURES` documentation.
If at any point the user tries to simplify by changin `set_property` to `set_target_properties` the code breaks.
To better train users, provide and example of how to set multiple
CUDA architectures with `set_target_properties`.
339dbc901f Help: Note that CMP0116 is recorded at the time of CC creation
e3740e020e Tests: Test Qt autogen target with CMP0116 set to WARN
cf34011ce7 Tests: Test per-CC behavior of CMP0116
3a95503512 Ninja: Use CMP0116 status recorded at time of custom command's creation
f01f10e8fb cmCustomCommand: Record value of CMP0116 at time of creation
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5848
Run the script:
Utilities/Sphinx/update_versions.py --since v3.19.0 --overwrite
Manually restore the 3.20 version for `cmake_path`, which was originally
part of 3.19 but reverted and restored in 3.20.
Since commit c2dc7e0f53 (Help: Convert genex documentation to sphinx
domain objects, 2021-01-15) we can use `:genex:` cross-references to
link to named generator expressions. Update some places to do this.
This is meant to demonstrate the capability, not as a comprehensive
sweep.
This change was originally made by commit 74b1c9fc8e (Explicitly specify
language flag when source LANGUAGE property is set, 2020-06-01,
v3.19.0-rc1~722^2), but it was reverted by commit 30aa715fac (Revert
"specify language flag when source LANGUAGE property is set",
2020-11-19) to restore compatibility with pre-3.19 behavior.
Implement the change again, but add policy CMP0119 to make this change
while preserving compatibility with existing projects.
Note that the `Compiler/{Clang,Intel,MSVC}-CXX` modules do not need to
specify `-TP` for their MSVC-like variants because we already use the
flag in `CMAKE_CXX_COMPILE_OBJECT`. Similarly for `Compiler/XL-CXX`
and `Platform/Windows-Embarcadero`.
Note also that this does not seem possible to implement for XL C.
Even with `-qsourcetype=c`, `xlc` complains about an unknown suffix:
`1501-218 (W) file /.../AltExtC.zzz contains an incorrect file suffix`.
It returns non-zero even with `-qsuppress=1501-218`.
Co-Author: Robert Maynard <robert.maynard@kitware.com>
Fixes: #14516, #20716
The `/GR` flag has been on by default since MSVC cl 14.0 from VS 2005.
Remove it from the default flags to make it easier for projects to pass
`/GR-` themselves to turn it off.
Projects may be using string processing to replace `/GR` with another
flag, so we cannot simply drop it. Add a policy to drop it in a
compatible way.
Fixes: #21428
`ExternalProject_Add_StepTargets` and `INDEPENDENT_STEP_TARGETS` have
some limitations and lack some sanity checks. They can cause confusing
build systems to be generated. The basic problems are:
* The notion of step independence is attached to the step target
rather than the step itself.
* The custom commands implementing the steps are duplicated in the
step targets and the primary targets. This can cause races.
It is also incompatible with the Xcode "new build system".
Fix this by introducing policy CMP0114 to change the way step target
dependencies are handled. Define independence from external
dependencies as a property of each individual step regardless of whether
there is a target for it. Add dependencies among the primary target and
the step targets such that each custom command only appears in one
target. When some steps are disconnected from the primary target, add
step targets for the steps commonly depended upon so that there is a
place to hold their custom commands uniquely.
Fixes: #18663
Do not attach a custom command to a target if it is already attached to one of
the target's dependencies. The command's output will be available by the time
the target needs it because the dependency containing the command will have
already been built.
This may break existing projects that do not properly mark non-created
outputs with the `SYMBOLIC` property. Previously a chain of two custom
commands whose intermediate dependency is not created would put both
commands in a dependent project's Makefile even if the first command is
also in its dependency's Makefile. The first command would run twice
but the build would work. Now the second command needs an explicit
`SYMBOLIC` mark on its input to tell CMake that it is not expected to
exist. To maintain compatibility with projects that left out the mark,
add a policy activating the behavior.
Only generate a graph dependency between a custom command and
a target when the custom command queries for the file path
of an artifact of the target.
This makes generator expressions such as `TARGET_FILE_DIR`
behave the same way as `TARGET_PROPERTY` which never generated
a graph dependency.
Previously we would synthesize <TARGET_NAME>-NOTFOUND as the location. This
would then end up on the link line and cause build failures.
Policy CMP0110 is added to control this behaviour.
Fixes#19080, #19943.
