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.
Add an `OPTIMIZE_DEPENDENCIES` target property and supporting
`CMAKE_OPTIMIZE_DEPENDENCIES` variable to optionally enable pruning and
flattening of outgoing dependencies from static libraries. Since they
do not actually link, they only depend on side effects of their
dependencies. Therefore we can drop dependencies that contribute no
side effects.
Restore the change from commit f84af8e270 (add_test: Allow special
characters in test name, 2020-05-16, v3.18.0-rc1~142^2) that had to be
reverted by commit f84af8e270 (add_test: Allow special characters in
test name, 2020-05-16, v3.18.0-rc1~142^2) for compatibility.
Add policy CMP0110 to make the change in a compatible way.
Also, support even more characters than before by generating the
test scripts using bracket arguments around the test names.
Fixes: #19391
Signed-off-by: Deniz Bahadir <dbahadir@benocs.com>
bafa9fe887 fileapi: Add INTERFACE libraries with SOURCES to codemodel-v2
4391913133 Add INTERFACE libraries to generated buildsystem if they have SOURCES
afb998704e Remove filtering of allowed INTERFACE library properties
e7edba2baf Makefiles: Use IsInBuildSystem in global generator target type checks
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5078
INTERFACE libraries were created with the intention of collecting usage
requirements for use by other targets via `target_link_libraries`.
Therefore they were not allowed to have SOURCES and were not included in
the generated buildsystem. In practice, this has become limiting:
* Header-only libraries do have sources, they just do not compile.
Developers should be able to edit those sources (the header files)
in their IDE.
* Header-only libraries may need to generate some of their header
files via custom commands.
Some projects work around these limitations by pairing each interface
library with an `add_custom_target` that makes the header files and
custom commands appear in the generated buildsystem and in IDEs.
Lift such limitations by allowing INTERFACE libraries to have SOURCES.
For those with sources, add a corresponding build target to the
generated buildsystem.
Fixes: #19145
f76c20da63 Toolchain: Test compiler initial settings
db486da265 Toolchain: Update documentation for initial compiler flags
deec2f587c Toolchain: Take CMAKE_<lang>_FLAGS_INIT into account during compiler detection
ca899af3e2 Toolchain: Handle repeated invocations of CMake with -DCMAKE_C_COMPILER
12ba89e142 Toolchain: Make `/path/comp;-argn' behave the same as 'comp;-argn'
6f1af899db Toolchain: Capture all arguments from CMAKE_<LANG>_COMPILER
ec1d3bc0b6 cmake: avoid exception when printing "changed variables" message
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4136
When a CUDA sdk doesn't have nvcc, defer to the existence of
a version.txt file. When we do this fall back we also reconstruct
the CUDA version via version.txt
Fixes#20643
This option has been broken since commit b9f9915516 (cmMakefile: Remove
VarUsageStack., 2015-05-17, v3.3.0-rc1~52^2). That commit removed the
check that an initialized variable has actually been used and caused the
option to warn on every variable ever set. This was not caught by the
test suite because the test for the feature only checked that warnings
appear when needed and not that they do not appear when not needed.
The option was never very practical to use. Remove it to avoid the
runtime cost of usage tracking and checks for every variable (which we
were doing even when the option was not used).
The GLSL SPIR-V compiler is part of the Vulkan SDK and may be used
by projects for compiling shaders as part of the build process.
This is not strictly required to build a Vulkan application, which
is why the variable is not part of the REQUIRED_VARs for the module.
Issue a deprecation warning on calls to `cmake_minimum_required` or
`cmake_policy` that set policies based on versions older than 2.8.12.
Note that the effective policy version includes `...<max>` treatment.
This is important in combination with commit ca24b70d31 (Export: Specify
a policy range in exported files, 2020-05-16, v3.18.0-rc1~133^2).
This fix was first made by commit 86e6349ef7 (find_program: Find
programs that are executable but not readable, 2020-04-04,
v3.18.0-rc1~372^2) but was reverted for compatibility. Re-introduce it
with a policy for compatibility.
Fixes: #10468
CPack learned the `CPACK_PRE_BUILD_SCRIPTS`, `CPACK_POST_BUILD_SCRIPTS`,
and `CPACK_PACKAGE_FILES` variables.
The first two are lists of scripts to perform
- after pre-install files into a staging directory and before
producing the resulting packages
- after produsing the packages
The post-build script(s) also get the list of actually produced
packages in the `CPACK_PACKAGE_FILES`.
Issue: #19077
The OLD behaviors of all policies are deprecated, but only by
documentation. Add an explicit deprecation diagnostic for policies
introduced in CMake 3.11 and below to encourage projects to port away
from setting policies to OLD.
The `CPACK_EXTERNAL_PACKAGE_SCRIPT` script may set this list variable to the
full paths of generated package files. CPack copy these files from the stage
directory back to the top build directory and possibly produce checksum files
if the `CPACK_PACKAGE_CHECKSUM` is set.
