Remove PROJECT support from try_run; it was never tested, has never been
documented, and it's unclear how it should even work (since CMake
wouldn't know what executable to run).
8fc822e13a file: Avoid strange istringstream crash in cmake.org binaries on Alpine Linux
31f158e4c8 cmStringAlgorithms: Add functions to parse strings to long long integers
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !7698
8fc822e13a file: Avoid strange istringstream crash in cmake.org binaries on Alpine Linux
31f158e4c8 cmStringAlgorithms: Add functions to parse strings to long long integers
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !7698
Somehow using `istringstream` and `operator >>` to parse an integer
crashes on Alpine Linux, at least when compiled with the settings we use
for the official `cmake.org` Linux binaries. Since commit fd0c285b12
(file: Fix types of the OFFSET and LIMIT arguments, 2022-01-04,
v3.23.0-rc1~133^2), this causes the `file(READ)` command to crash when
parsing its `LIMIT` or `OFFSET` argument. Parse the input string with
our dedicated helper to avoid the crash.
Fixes: #23872
This test ensures we can configure and build mixed source binaries. The
test configures, but fails to verify due to multiple targets emitting
the `lib.c.o` and `lib.cpp.o` outputs. Both the clang build step and the
swift link step report that they emit the `lib.c.o` and `lib.cpp.o`
outputs. The `.o`'s are emitted by clang, not by swift.
Link policy explaining BYPRODUCTS.
Apply the change from commit 00b788e85e (Help:custom_command: link
policy on BYPRODUCTS, 2022-09-09) to `add_custom_target` docs too.
Issue: #23786
Modify modules that ship with CMake and use the project flavor of
try_compile to use the new signature added by commit 56ae40cc59
(try_compile: Add PROJECT keyword-dispatched signature, 2022-09-14).
With how things were before, mixed Swift/C++ libraries would result in a
broken ninja file. `cpp.cpp.o` was emitted by the compiler, but was
also being included in the `linkBuild.Outputs` list, so it was being
emitted by multiple targets.
The fix checks that the source language is Swift before adding it to the
list of additional outputs. If it is Swift, this isn't a problem. If it
isn't Swift, we don't include it in the list of outputs.
On the other side, the C++ file was also being passed as a source file,
which the Swift compiler can't compile. So we add the C++ object file as
an explicit dependency and the object file is then added to the list of
Swift sources.
The previous fix for #21772, commit 005e2cdfb0 (Android: Do not use gold
for ndk >= r22, 2021-02-26, v3.20.0-rc3~1^2), doesn't work with typical
android toolchain file, like this one:
https://android.googlesource.com/platform/ndk/+/master/build/cmake/android-legacy.toolchain.cmake
The condition fails to work when CMAKE_ANDROID_NDK_VERSION is undefined:
second part evaluates to true, although ndk version is not known.
I've encountered following environment where CMAKE_ANDROID_NDK_VERSION
is used without definition:
* Build uses android toolchain file, which sets CMAKE_SYSTEM_VERSION=1
and doesn't set CMAKE_ANDROID_NDK_VERSION.
* Code in Platform/Android-Determine.cmake exits early when it detects
toolchain usage (via value CMAKE_SYSTEM_VERSION=1). This file is the
only place in cmake modules where variable CMAKE_ANDROID_NDK_VERSION
is set, and by early return we skip this definition.
Honor the OpenSSL environment variables used to specify the location of
the TLS certificates, as specified in the `curl(1)` man page.
Co-authored-by: Ludovic Courtès <ludo@gnu.org>
