Extract the `install_swift_interface` function into a new file. This
is always invoked to perform the installation of the Swift interfaces as
well as the binary module. Additionally, it prepares for a future
refactoring which will also install the swift documentation interface.
If you use SwiftStdlibCurrentOS availability, you will be able to
use new types and functions from within the implementation. This
works by, when appropriate, building with the CurrentOS availability
set to the current deployment target.
rdar://150944675
Introduce install targets for the StringProcessing module. This is a
prerequisite for building a static variant of the standard library to
enable the statically linked early swift driver for Windows to
bootstrap.
Adds common CMAKE modules to be used by the supplemental libraries.
Namely:
* ResourceEmbedding
* PlatformInfo
* gyb
* EmitSwiftInterface
* CatalystSupport
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).
The new build system set `SWIFT_RUNTIME_CLOBBER_FREED_OBJECTS` to 0.
Unfortunately, the check in the Swift runtime used `#ifdef`, so even
though it was turned off, it was actually enabled in some cases.
Fixing the issue in the build system as well as switching the check to
verify that value of `SWIFT_RUNTIME_CLOBBER_FREED_OBJECTS` is taken into
account in the sources. C/C++ implicitly defines macro values to 1 when
set without a value and 0 when it is not set.
Also making the hex a bit more recognizable and grep'able by including
it as a comment.
Fixes: rdar://149210738
We need this so that older compilers can handle the .swiftinterface
files we generate. It's unnecessary for newer compilers and can be
removed later.
Fixes rdar://148529962.
Explicit module builds help prevent the dependency scanner from getting
lost and attempting to pull the SwiftShims module from the resource
directory, existing SDK, and the just-built standard library.
They aren't part of the library interface, but make it possible to build
the runtime libraries without seeing duplicate shims. Moving the flag to
a top-level compile command.
When building the standard library, the SDK is not fully staged and so
the compiler would not be able to inject the VFS overlay for the
modularisation of the Windows SDK. Manually construct the mappings and
apply them.
The expected install locations for the SwiftCoreConfig.cmake and
SwiftCoreTargets.cmake file was inconsistent between the build directory
and the install location. Making everything consistent across install
locations. In both cases, the files are installed under
`./cmake/SwiftCore`. This is one of the formats that `find_package` uses
to automatically search for package config files so that we can avoid
passing `SwiftCore_DIR` to all sub-projects.
We want to move StringProcessing sources out of the experimental string
processing repository. Use the Resync script to copy the files from the
experimental repository into position in the StringProcessing library.
This removes the workaround for the exporting of the registrar and
enables proper dependency tracking across projects (primarily geared
towards the Overlay).
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.
Explicitly add the path to the Swift module to the interface include
directories. It is unclear why this is not propagating implicitly from
the module definition. For now, this ensures that the client is able to
load the standard library.
When building the runtime, we do not know how it will be loaded even if
it is static. Default to building in PIC mode for non-Windows targets
(Windows is always implicit PIC).
