58c05e1c73 Xcode: Use "Link Binary With Libraries" build phase when possible
927373b678 Xcode: Refactor generator variable names and types
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4882
742ff97f80 Refactor language standard computation
0892c798f7 cmMakefile: Change CompileFeatureKnown to take target name instead of target
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4803
bdb105ee94 Help: Mention CUDA Clang limitations in 3.18 release notes
fec7dd33d3 CUDA: Add issue number to Clang separable compilation error
14163d7d6b CUDA: Throw error for Clang on Windows
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4903
Try linking all target linked libraries through frameworks build phase
instead of linker flags, thus letting Xcode manage build product paths
correctly. Prevent adding duplicate entries to "Link Binary With
Libraries" build phase.
Add check for configuration-dependent linking - in case the library is
not present in all configurations revert back to linker flags which are
per-configuration.
This does change the order of libraries linked, but that does not seem
to matter for Apple linkers invoked by Xcode, even for static libraries.
The linker will go back and re-consider a static library from earlier
on the link line when more symbols from its objects are needed.
Fixes: #14185
cmCoreTryCompile had significant code duplication around handling
languages that offer standard levels. This refactoring reduces
the complexity and makes it easier to add new languages in the
future.
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
b9dd072e05 Tests: Add case for cmake --build with a failing target
87c860ebad cmake --build: Fix exit code when building multiple targets
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4878
The ability to disable adding architectures completely for packaging purposes
and cases requiring passing the architectures flags explicitly has been
requested.
Support a false value for CUDA_ARCHITECTURES and CMAKE_CUDA_ARCHITECTURES
for this purpose.
Implements #20821.
cc02ced530 find_program: Revert "Find programs that are executable but not readable"
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4871
cc02ced530 find_program: Revert "Find programs that are executable but not readable"
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4871
Clang isn't very good at finding the installed CUDA toolkit.
The upstream recommendation is that we should pass the toolkit explicitly.
Additionally:
* Avoids Clang having to search for the toolkit on every invocation.
* Allows the user to use a toolkit from a non-standard location by simply
setting CUDAToolkit_ROOT. The same way as with FindCUDAToolkit.
Clang wants the directory containing the device library and version.txt as the
toolkit path.
We thus pass the newly introduced CUDAToolkit_LIBRARY_ROOT as the toolkit path.
We save CUDAToolkit_ROOT_DIR and CUDAToolkit_LIBRARY_ROOT on Clang to have them
available in try_compile() and avoid unnecessary re-searching or a possibly
different installation being found in FindCUDAToolkit.
This however means that the selected toolkit can't be changed after the initial
language enablement.
We now determine CUDA compiler ID before doing actual detection, as we don't
want to spend time finding the CUDA toolkit for NVIDIA.
Implements #20754.
Updated the cmGlobalGenerator::Build method to check the return `retVal`
parameter supplied to the `cmSystemTools::RunSingleCommand` to validate
that each invocation of the build command returned an exit code of zero.
Fixes: #20790
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.
