Filter out `-Wunused-command-line-argument` warnings from Clang (that
can be caused by user-specified flags) so that they do not break our
checks for C++ feature availability.
This extends commit 71b65abca2 (C++ feature checks: Filter out warnings
caused by user flags, 2017-09-19, v3.10.0-rc1~90^2).
Wire up the flags needed to support module libraries built and used with
Swift. We need to pass `-bundle` to the linker when linking module
libraries on Darwin, and we need to pass `-export-dynamic` to the linker
when emitting an executable that exports symbols on Linux. This patch
wires up `CMAKE_SHARED_MODULE_CREATE_Swift_FLAGS` and
`CMAKE_SHARED_MODULE_LOADER_Swift_FLAG` on Darwin, and hooks up
`CMAKE_EXE_EXPORTS_Swift_FLAG` on Linux in order to support passing
things correctly.
We can't expose `CMAKE_EXE_LINKER_FLAGS` to Swift, as it contains flags
that the Swift compiler doesn't recognize, but the other
language-specific variables are safe to expose.
Since last commit on this topic on Jan 15, 2024, nightly testing has found
some other CPack tests failing on broken libc on Elbrus, which was revealed
after transition to libuv. These tests are excluded in this condition.
This is needed for C++ modules because `import std` support may differ
based on the standard library implementation. Extract the information as
necessary.
Compilers may implement this by implementing a `_cmake_cxx_import_std`
function which takes the standard version as an argument (e.g., `23`)
and creating a target named `CMake::CXX${std}` that represents how
`import std;` should be represented within CMake.
In commit ff6c401309 (cmTarget: Add interface for compatible numeric
properties, 2013-10-22, v3.0.0-rc1~460^2) the condition
dagCheckerParent && !dagCheckerParent->EvaluatingLinkLibraries()
was written that way to avoid a nullptr dereference, but is actually
meant to say "is not evaluating link libraries". That can also be true
when there is no `dagCheckerParent`, such as when evaluating a generator
expression outside of usage requirements, e.g., for `add_custom_target`.
The original commit tried to account for that by duplicating the
implementation in another code path, but that did not work in all cases.
Fix the condition, remove the duplication, and enable tests for the
now-working cases.
The `IsLinkInterfaceDependent*Property` methods internally exclude
INTERFACE libraries since commit 0bfcb450e6 (INTERFACE_LIBRARY: Avoid
codepaths which set unneeded properties., 2013-11-20, v3.0.0-rc1~301^2~1).
Thread-local variables are put in the tdata section on AIX / XCOFF [1]. Unfortunately
the ExportImportList script currently doesn't consider this section when looking for
symbols to export.
This results in linking failures in applications (such as LLVM) when building which expect these thread local variables to be exported from their shared libraries.
[1]: https://www.ibm.com/docs/en/aix/7.3?topic=formats-xcoff-object-file-format
For `import std;` support, CMake needs to know the standard library
involved in order to ensure that the right target is linked. Afterwards,
the created synthetic targets need their target compile features
computed.
Brad King