- deduplicate the logic to compute the resource folder
- install headers and module files in shared and static resource folders
- forward -static flag when calling swiftc with -print-target-info
Clean up a few general patterns that are now obviated by canImport
This aligns more generally with the cleanup that the Swift Package
Manager has already done in their automated XCTest-plumbing tool in
apple/swift-package-manager#1826.
Platform defines sem_open in Swift that calls through to the underlying
platform functions because sem_open is variadic. However, the
definitions here assume sem_t is non-nullable, but this assumption only
holds when the platform has nullability annotations on the semaphore
type, or the semaphore type on the platform is not an opaque pointer.
On OpenBSD specifically, the semaphore type is an opaque pointer without
any nullability annotations. This means that the type gets inferred as
UnsafeMutablePointer<sem_t?>? instead of UnsafeMutablePointer<sem_t>?.
To make sure the pointer values returned and their types match, we
introduce a conditional typealias.
The other option is to coerce everything to UnsafeMutablePointer<sem_t>?
but this would be a rather blunt instrument. While sem_open is public in
stdlib, it is not so much codified stdlib API, so this is a slightly
nicer approach.
The non-C/C++ standard defined math constants require
`-Xcc -D_USE_MATH_DEFINES` when using the `ucrt` module. Instead,
provide them through the wrapper `MSVCRT` module as aliases so that the
user does not need to be aware of this in practice.
Repairs the Windows build of `_Differentiation`.
Commit for CMake and build scripts to recognize OpenBSD. To keep this
commit relatively short, this just deals with the rather simple and
uncontroversial changes to the build system.
Note that OpenBSD calls "x86_64" as "amd64", Since the Swift stdlib will
be put in a subdirectory named after ARCH, to ensure the standard
library is properly found later, we use the native architecture name for
OpenBSD in the build system rather than trying to deal with the
difference the other way around.
I've verified that all of the header files in this module already
contain their own `extern "C"` blocks that are activated if compiling as
C++.
The additional [extern_c] attribute causes problems for some headers,
like PathCch.h, that define additional overloads of functions when
compiled as C++. The "global" [extern_c] essentially switches off name
mangling with these overloads, which causes them to conflict with the
functions they are overloading.
See here for more context:
https://github.com/apple/swift/pull/30233#issuecomment-601594221
See here for an example of failures caused by the [extern_c]:
https://ci-external.swift.org/job/swift-PR-windows/869/console
(Search for "PathCch.h".)
Provide a separate modulemap for OpenBSD's libc, rather than try to
continue to overload the modulemap for glibc, since glibc has its own
idiosyncracies.
These should hopefully all be uncontroversial, minimal changes to deal
with progressing the build to completion on OpenBSD or addressing minor
portability issues. This is not the full set of changes to get a
successful build; other portability issues will be addressed in future
commits.
Most of this is just adding the relevant clauses to the ifdefs, but of
note in this commit:
* StdlibUnittest.swift: the default conditional in _getOSVersion assumes
an Apple platform, therefore the explicit conditional and the relevant
enums need filling out. The default conditional should be #error, but
we'll fix this in a different commit.
* tgmath.swift.gyb: inexplicably, OpenBSD is missing just lgammal_r.
Tests are updated correspondingly.
* ThreadLocalStorage.h: we use the pthread implementation, so it
seems we should typedef __swift_thread_key_t as pthread_key_t.
However, that's also a tweak for another commit.
The build scripts assume Android cross-compilation using the NDK, so avoid
that configuration if building on an Android host. Fix or disable some tests,
and don't install a glibc.modulemap without a native sysroot prefix.
This enables the use of the math defines when building tgmath.swift.
Although not used in the normal branch, this define is necessary to
build the swiftMSVCRT module for TensorFlow which uses the math
constants.
Now that CMAKE_HOST_SYSTEM_NAME and CMAKE_SYSTEM_NAME are set by default to
Android in the Termux app, make the needed tweaks. Some tests were adapted
to work natively on Android too, adds sys/cdefs.h to the Bionic modulemap,
and includes the start of native Android platform support in the build-script.
The Bionic modulemap was missing the autolinking information against
libm, so using the module math functions might have hit undefined
symbols (it was happening in TestDecimal in Foundation for me). The line
is present in the Linux glibc.modulemap, but was not there for Android
Bionic modulemap.
* Revert "Add availability information to the new Math function protocols (#24187)"
This reverts commit d2f695935f.
* Revert "SE-0246: Protocols and static functions (#23824)"
This reverts commit 57a4553832.
* Expected abi changes.
This commit introduces a CMake target for each component, adds install targets
for them, and switches build-script-impl to use the target `install-components`
for installation. Each of the targets for each component depends on each
of the individual targets and outputs that are associated with the
corresponding swift-component.
This is equivalent to what already exists, because right now install rules are
only generated for components that we want to install. Therefore, this commit
should be an NFC.
This is a resubmission (with modifications) of an earlier change. I originally
committed this but there were problems with some installation rules.
This commit introduces a CMake target for each component, adds install targets
for them, and switches build-script-impl to use the target `install-components`
for installation. Each of the targets for each component depends on each
of the individual targets and outputs that are associated with the
corresponding swift-component.
This is equivalent to what already exists, because right now install rules are
only generated for components that we want to install. Therefore, this commit
should be an NFC.
This makes it more explicit what the install component of a target
library is if you don't see one (and its marked as IS_SDK_OVERLAY).
Explicit in this case makes more sense, as you don't have to rely on
knowledge of how `add_swift_target_library` is implemented to understand
what component is used to install the target.
This extends the WinSDK module definition further to better modularise
the headers. This should improve the header organisation as well as
setup additional autolink rules.
Be more aggressive about using the autolinking functionality of modules
on Windows. This makes it easier to use WinSDK in Swift as the link
dependencies are implicitly taken care of.
There are situations where you want to build against a libc that is out
of tree or that is not the system libc (Or for cross build scenarios).
This is a change for passing the -sdk and include paths for things like
this.
Rather than hardcoding the paths to /usr/include, allow the user to set
the path to their libc headers. This is particularly important for
environments which may not use the traditional layout (e.g. exherbo) or
for builds which wish to build against an out-of-tree, non-system
installed libc for a Unix target which does not match the host system
(i.e. foreign cross-compilation).
This splits out the bionic modulemap from the glibc modulemap. They are
sufficiently different that the duplication is worth it. Furthermore,
it will enable properly identifying the libc on android. Once fully
detangled, this will enable the use of bionic on non-android platforms.
