This is basically the same as the one for Linux, but it would be
somewhat awkward to add the platform conditional on a file named for
Linux when OpenBSD is not Linux.
Important note: if Dispatch is disabled, then this will cause a
compilation error (probably not just for OpenBSD either), because
PlatformExecutorFactory is both defined in PlatformExecutorNone.swift
and PlatformExecutor<...>.swift in this case.
Because this only bites OpenBSD bootstrap builds, and since OpenBSD
support has been upstreamed to Dispatch, default to the Dispatch
implementation for now to get this in, and we'll refactor in a different
pr.
These libraries use C++ as the linker language which will prevent
`CMAKE_STATIC_LIBRARY_PREFIX_Swift` from impacting them. Wire this
property to the target manually so that it takes effect. This is
primarily meant to support Windows, where we use a non-standard library
prefix for static libraries mirroring the behaviour of the language
runtimes (i.e. ucrt, vcruntime, msvcrt).
swiftCore and swift_Concurrency libraries use C++ and Swift. The C++
does not use the Swift C++ interop. Swift driver only uses clang++ to
link when building in C++ interop mode and there currently isn't a flag
to change that. Since we're explicitly linking the runtime registration
when necessary and do not need compatibility libraries, it is safe to
use clang++ as the linker directly, instead of going through swiftc.
In versions of CMake older than 3.29, Swift is always used as a linker
and has no compile stage. By using clang++ as the linker, we require the
split build model (CMP0157), so we cannot allow versions of CMake older
than 3.29.
This is required to use the SwiftCore package externally via
`find_package` when Concurrency is enabled. We are otherwise unable to
process the CMakeLists due to the missing dependency from the export
set.
`swiftrtT.obj` should be used for statically linking the standard
library (or within the standard library itself). For the other modules,
we need to differentiate between `swiftrt.obj` and `swiftrtT.obj`. This
fixes that oversight. This was not caught by the CI builds as we do not
currently build both the static and dynamic variants of the new
runtimes.
* [Concurrency] Initial steps for startSynchronously for Task
* [Concurrency] Rename to _startSynchronously while in development
* [Concurrency] StartSynchronously special executor to avoid switching
* startSynchronously bring back more info output
* [Concurrency] startSynchronously with more custom executor tests
* add missing ABI additions to test for x86
* [Concurrency] gyb generate _startSynchronously
* [Concurrency] %import dispatch for Linux startSynchronously test
* [Concurrency] Add TaskGroup.startTaskSynchronously funcs
* [Concurrency] DispatchSerialQueue does not exist on linux still
The dispatch global executor depends on finding dispatch. If dispatch is
not found, it will fail to build. Mark it as required to get a
configuration failure early.
Starting to work on a full installation story for the Swift runtimes.
This involves generating the SwiftCoreConfig cmake files to allow
importing the just-built runtimes into the overlays and supplemental
libraries, setting up the flags appropriately for the given SwiftCore
build configuration.
This also separates out the development and runtime components to allow
installing just the runtimes without the headers.
Component List:
- SwiftCore_runtime
The runtime libraries that are required for running code.
- SwiftCore_development
The interface with the runtime libraries that are required for
building code against the runtimes.
- SwiftCore_cmake
Files for interfacing CMake projects with the built runtimes.
This includes the target list and flags needed to use the targets
built by the specific configuration used to build the runtime
libraries.
These files are used for mapping flags, definitions, and locations
into the overlay libraries and supplemental libraries.
This adds install commands for the object libraries contributing to
libswiftCore so that they are represented in SwiftCoreTargets.cmake.
Object libraries do not contribute anything to the files actually
installed.
To keep things consistent with the target and target-variant swiftmodule
files, moving the installation of the binary swift module into
`install_swift_interface`. CMake implicitly generates the target
swiftmodule, but does not know about zippered binaries, so we need to
ensure that the target-variant module is available for installation when
applicable.
This adds the `swift_Concurrency` module to the new runtimes build. This
is sufficient to build the code but will require further fine tuning to
ensure that all the flags entirely identical and that the ABI surface is
also fully replicated.
