When using `dpkg-shlibdeps` to automatically determine package
dependencies it considers the RUNPATH/RPATH of executables in order to
find all required shared libraries of such executables.
If the RUNPATH/RPATH contains a verbatim `$ORIGIN` (respective
`${ORIGIN}`), it will now be substituted by the packaging-paths of other
components that are marked as dependency and those paths will then be
used as additional search directories for `dpkg-shlibdeps`.
Associated tests were added as well.
Fixes: #21838
FETCHCONTENT_FULLY_DISCONNECTED should only be set to true if
each dependency's source directory has already been populated.
Previously, this wasn't being checked, but now it is (subject to a new
policy).
Previously, FetchContent was relying on the policies of the
includer being compatible with the module. That made the
module vulnerable to subtle problems where policy settings
might lead to unexpected behavior.
With this change, we now specify the policies for as much of
the module as we can without breaking backward compatibility.
Only a few specific implementation details of the
FetchContent_MakeAvailable() macro have to remain uncontrolled
due to the way those parts can invoke user or project code which
may be relying on the includer's policy settings (intentionally or not).
`nvcc` from CUDA < 12.4 does support the MSVC 14.40.17.10 toolset.
Users may specify `CUDAFLAGS=-allow-unsupported-compiler` to bypass the
check. However, we do not use arbitrary user-specified flags during
compiler identification in the VS generator because escaping them for
the `AdditionalOptions` of the `.vcxproj` file requires non-trivial
logic that we currently only implement in the C++ generator code.
Instead, just always pass `-allow-unsupported-compiler` during CUDA
compiler identification in the VS generator.
Fixes: #26003
23c91b55d6 ADSP: Treat .s files as asm sources
43b5e88fe6 ADSP: Preserve ASM output ext and flags as we do for C and CXX
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9530
7bf15e49a8 ExternalProject: Fix misleading git update output
b2496bf14c FetchContent: Populate directly without a sub-build
173daad58d ExternalProject: Move more internal commands out of main file
462e583267 ExternalProject: Switch download, update and patch to use _EP_ vars
0ccc8e340d ExternalProject: Provide ExternalProject_Add keywords through a macro
91e1015722 ExternalProject: Don't treat YES as a keyword
a1743ce1ef ExternalProject: Fix minor formatting error
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: scivision <michael@scivision.dev>
Merge-request: !9513
When re-running the build with the git download method,
and where GIT_TAG is set to a tag name that we already have
locally from the first run, the second run will skip the update
step if it is already at the requested tag. The message in this
case was previously printing the commit hash instead of the
tag name, which was wrong. This wasn't noticed before
because that output wasn't usually shown, but we now do
show that message after making message output log levels
more consistent between the steps.
On platforms that semantically distinguish loadable modules (plugins)
from shared libraries, such as macOS and CYGWIN, fix the per-language
fall back to create them the same way as with the C toolchain even when
the C language has not been enabled.
The `Platform/<OS>.cmake` modules record platform-specific flag
variables for the C toolchain. The `CMake<LANG>Information` modules
initialize the per-language platform-specific flag variables to defaults
copied from C. However, they have diverged over time, and not all
platform-specific flag variables are initialized correctly for all
languages. Factor out the CXX language's instance of this logic into a
helper macro, and reuse it for all languages for which we previously
had the platform-specific flag variables at least partially filled out.
Previously the Fortran language's copy of this logic used
`if(NOT DEFINED <var>)` instead of just `if(NOT <var>)` to allow
`Platform/<OS>-<COMPILER_ID>-<LANG>` modules to specify empty values for
some platform-specific flag variables without being overridden.
Use this approach in the helper macro so it applies to all languages.
Fixes: #25990
6e5e7968c3 GenEx $<LINK_LIBRARY>: Add the support of properties attached to features
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9510
Top-level code only works as part of executables, which breaks when
`CMAKE_TRY_COMPILE_TARGET_TYPE` is set to `STATIC_LIBRARY`. This patch
fixes the test to something agnostic between executables and libraries
while still verifying that we can import types from the standard
library.
Fixes: #25984
Revert commit cabad8a37f (ExternalProject: Always use $<CONFIG> for
source files, 2023-02-02, v3.27.0-rc1~550^2~3) and restore
Xcode-specific behavior intentionally preserved by commit c111d440ce
(ExternalProject: Express per-config step stamp file paths using CONFIG
genex, 2022-06-08, v3.24.0-rc1~15^2). Unfortunately we still do not
have a test case, so leave a comment to avoid reverting this.
Issue: #23645
Issue: #23652
The commands moved to shared_internal_commands.cmake
will soon be used directly by FetchContent, which cannot
always include the full ExternalProject.cmake file (e.g. it may
be used in CMake script mode).
Issue: #21703
This refactoring prepares for the download, update, and
patch steps being called directly from FetchContent instead
of always being in a sub-build. When there is no sub-build,
there will be no targets to read properties from. This commit
moves the information to _EP_... variables, which will always
be readable.
Issue: #21703
This allows things outside of ExternalProject to have access
to the list of supported keywords. This will be used by
FetchContent in an upcoming change.
Issue: #21703
This ultimately won't change behavior, since YES should never be listed
in the "keywords" argument. The original code looks like a bug though,
since YES satisfies the criteria for being interpreted as a keyword, and
there is logic to short-circuit on TRUE and FALSE. Add YES to that
condition to avoid any potential confusion.
Add the following variables:
* Python_EXECUTABLE_DEBUG
* Python_INTERPRETER
* Python_DEBUG_POSTFIX
and target Python::InterpreterDebug.
python_add_library() command Manage DEBUG_POSTFIX target property based
on the value of Python_DEBUG_POSTFIX variable.
Fixes: #25874
Brad King
domke
Deniz Bahadir
Robert Maynard
Ian McInerney
Craig Scott
Pablo Romero
Jonathan Schwender
Rupert Clarke
Evan Wilde
Ben Boeckel
Marc Chevrier
scivision