The can_fetch_default variable needs to be set before the call to
_ep_write_gitupdate_script(). Move it to before that call and always
set the variable, even if arg_SCRIPT_FILE is not set. This makes the
generated git update script file easier to follow if someone tries to
follow what it is doing or wants to investigate problems and run it
manually.
Fixes: #26164
In 462e583267 (ExternalProject: Switch download, update and patch to
use _EP_ vars, 2024-05-13), the svn_username and svn_password variables
were only updated appropriately in the svn download implementation, but
not in the svn update implementation. This was easily missed in part
because the old implementation was relying on behavior that differed
from the documentation for get_property(), and the new implementation
tried to keep the intermediate variables from the old implementation but
missed this subtle aspect.
Issue: #26152Fixes: #26148
Skip the `CMAKE_OSX_ARCHITECTURES` validation added by commit db409e5e68
(APPLE: Check if compilers respect CMAKE_OSX_ARCHITECTURES, 2024-05-04,
v3.30.0-rc1~15^2) if the value contains a placeholder, since we do not
know the real value.
Fixes: #26128
Revise commit 657064b6d4 (FindMatlab: Refactor: Eliminate
_matlab_64Build, 2024-01-24, v3.30.0-rc1~594^2~5) to more faithfully
reproduce the original behavior.
Revise commit 91c672e5ae (FindMatlab: Use find_package(Threads) instead
of checking -pthread, 2024-02-02, v3.30.0-rc1~594^2~1) to restore the
old behavior of looking for threads only with C or CXX enabled.
Fixes: #26121
In commit 60661f6770 (CPack/WiX: Make InstallScope configurable,
2023-11-07, v3.29.0-rc1~413^2) the `CPACK_WIX_INSTALL_SCOPE` default was
set to `perMachine`. While installers created with `perMachine` have
better behavior on their own than installers created without any
`InstallScope`, they do not cleanly convert existing installations on
updates.
Fixes: #26029
This patch improves the wording of the documentation of the
EXCLUDE_FROM_ALL directory property, and makes the
add_subdirectory()- and fetchcontent-documentation refer to it.
Not all compilers that can be used on APPLE platforms will respect
the architecture(s) set in CMAKE_OSX_ARCHITECTURES and some will
not raise an error if they are unable to do this. For instance,
GCC will accept ignore additional architectures specified after the
first -arch XXX (with a non-fatal warning) and will even link the
simple test applications used in the ABI determination (and other
tests that don't require external libraries) if an architecture
is requested for which it doesn't have the required "multilib"
set-up.
Prevent unexpected build results or build failures that may occur
after a lengthy build process: verify that the binary used to obtain
the ABI information contains the requested architectures.
Fixes: #25952
This allows particular frameworks to be targeted by
particular dependencies, and for empty dependency
groups to satisfy NuGet's framework-matching
requirements.
The file(MAKE_DIRECTORY) implementation checks whether a path is
allowed to be written to before it checks if it already exists. For the
scenario where a SOURCE_DIR is an existing directory within the main
project's source directory, this triggers a fatal error if
CMAKE_DISABLE_SOURCE_CHANGES is set to true for ExternalProject,
and some FetchContent scenarios. Therefore, add an explicit check for
existence first to avoid making such error-triggering calls.
Fixes: #21872
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).
