Add an `INSTALL_JOB_SERVER_AWARE` option to `ExternalProject_Add`.
When using an explicit `INSTALL_COMMAND`, the generated commands
won't use `$(MAKE)` thus failing to connect to the outer make's
job server. Add an option enable explicit job server integration.
This is the install step's equivalent to the build step's
`BUILD_JOB_SERVER_AWARE` option added by commit bc43398e72
(ExternalProject: Enable Make Job Server with Explicit Build Command,
2023-08-09, v3.28.0-rc1~217^2). It is useful when the external
project's installation is driven by its build system. Note that with
Makefile generators, our default install command does use `$(MAKE)` to
connect to the outer make's job server.
Issue: #26398
Two features in FindPkgConfig were added in a CMake version where
they were initially broken, and could only be used once the
implementation was fixed in a later version.
Previously, the docs contained a `.. versionadded` tag denoting the
version where the _broken_ implementation was introduced (its true
"version added", if we're being literal), with a comment in the
documentation source noting that the feature didn't actually work
correctly until whatever later version the comment specifies.
Since that's completely backwards, from a user perspective, reverse
the documentation so that the `.. versionadded` message shows when
the feature first worked **correctly**, with a comment noting that
support was technically introduced in an earlier version, but in a
broken/nonfunctioning state.
Setting the `armlink --list` option without other diagnostic flags is
misleading because it produces an empty file and prevents the user from
printing diagnostics to the standard output or redirecting them to
another file.
It's unclear why the flag was added when support for ARMClang was first
added by commit 7b0abaac31 (ARMClang: Add support for Clang-based ARM
compiler, 2019-05-13, v3.15.0-rc1~111^2).
Fixes: #21538
Since commit 11da882a12 (Apple: Introduce separate system name for iOS,
tvOS, and watchOS, 2018-01-15, v3.14.0-rc1~14^2~1) our toolchain
inspection steps, like ABI detection, tell `try_compile` to use a
`STATIC_LIBRARY` instead of an `EXECUTABLE`. This was needed at the
time to avoid codesign requirements. However, commit d3a64c4e3f (Xcode:
Explicitly turn off signing in try_compile projects, 2020-07-16,
v3.19.0-rc1~483^2) introduced a more general solution to that problem.
Restore linking during toolchain inspection so that we can detect and
identify the linker.
Suggested-by: Marc Chevrier <marc.chevrier@gmail.com>
Fixes: #26443
007d7ea648 GoogleTest: Avoid extra call to set DISABLED test property in discovery
9a24c1e802 GoogleTest: Clear script content buffer on flush and flush less often
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !9982
007d7ea648 GoogleTest: Avoid extra call to set DISABLED test property in discovery
9a24c1e802 GoogleTest: Clear script content buffer on flush and flush less often
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !9982
When bootstrapping Debian for musl-linux-any, the multiarch directories
are not found due to an overly-specific regular expression.
See https://bugs.debian.org/1085507 for the original bug report.
The following platforms were missing:
* Android
* WindowsCE, WindowsPhone, WindowsStore and WindowsKernelModeDriver
And enhance various Apple platforms support (iOS, tvOS, etc...)
Fixes: #26439
The `magick-baseconfig.h` header has been moved to a different subdirectory.
See https://bugs.debian.org/1087233 for the original bug report in Debian.
For very long test names, this can noticeably reduce the size of the
generated file contents when tests are disabled. This change reduces
how far beyond the flush threshold the content can grow before being
flushed.
Issue: #26431
There's no need to check if flushing is needed after every command
is added to the variable holding the script content. It is enough to only
check once per test name. This simplifies the flushing logic, removing
the need for a separate flush_script() command. Previously, we were
not clearing the flushed script contents in all cases, but this is now
rigorously enforced at the one location where flushing is performed.
Also simplify the flushing of the list of test names, since that too doesn't
need a separate command. It is simpler and safer to handle that
directly inline where the one call to flush_tests_buffer() was
previously being made.
Fixes: #26431
Add a way to specify, in a portable way, to raise an error for any
warning during the link step. For that purpose, define:
* CMAKE_LINK_WARNING_AS_ERROR variable
* LINK_WARNING_AS_ERROR target property
Fixes: #25343
Update the list of known versions.
Run the command
cmake -DBOOST_DIR=/path/to/boost_1_86_0 \
-P Utilities/Scripts/BoostScanDeps.cmake
to extract dependencies from the 1.86.0 source tree.
They are the same as 1.85's dependencies, so just update
the version check for warning about newer versions.
Fixes: #26433
On modern macOS, compiler wrappers like `/usr/bin/cc` automatically
choose a SDK to pass via `-isysroot` to an underlying compiler from
Xcode or the CommandLineTools. Other toolchains like Homebrew's `gcc-*`
come with a default SDK too. Therefore, when targeting macOS, we no
longer need to choose any SDK or pass an `-isysroot` flag by default.
Update initialization of `CMAKE_OSX_SYSROOT` to be empty by default when
targeting macOS.
Fixes: #19180
Since commit 03ab170fe0 (OS X: Enable command-line build without tools in
PATH, 2013-08-05, v2.8.12~111^2) we find compilers such as
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
when there is no corresponding compiler in the PATH. However, modern
macOS versions always have `/usr/bin/cc` in the PATH, so this code path is
never taken (similarly for `make`). Even if it were, the compilers in
Xcode cannot be used by build systems that do not add an `-isysroot` flag.
Instead, they should be used through the `/usr/bin/cc` wrapper, which
internally calls Xcode's compiler with a default `-isysroot` flag.
Revert commit 1f085e11e4 (OS X: Resolve compiler in /usr/bin to that
reported by Xcode xcrun, 2015-01-03, v3.2.0-rc1~126^2~1). The compilers
in Xcode cannot be used by build systems that do not add an `-isysroot`
flag.
Issue: #19180
When `-pipe` is enabled, GCC passes data among its different executables
using pipes instead of temporary files. This leads to issues when cmake
attempts to infer compiler internals via the `-v` flag as each
executable will print to `stderr` in parallel. Avoid this by stripping
`-pipe` from the compilation flags during compiler inspection.
This extends commit d5895f50c3 (CMakeDetermineCompilerABI: Avoid failing
on warnings with -Werror, 2020-01-30, v3.17.0-rc1~32^2).
34067963cc LFortran: Improve detection of implicit link information for lfortran 0.40+
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9939
34067963cc LFortran: Improve detection of implicit link information for lfortran 0.40+
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9939
