Implementing an initial `Finddispatch.cmake` module to find Dispatch
from the system SDK on Apple platforms. Still should implement a basic
mechanism for finding it on Windows and Linux. Note that those platforms
will likely use the dispatch config mechanism most frequently, but this
should still work as a fallback.
This mechanism is the only one that works for Apple platforms though as
those use libdispatch from the SDK rather than building it with
corelibs-libdispatch.
When building for Linux and Windows, it is possible to build a custom
corelibs-libdispatch runtime with `dispatch_DIR` and avoid this module.
This module makes it possible to use a pre-built corelibs-libdispatch
when one is available without needing to build it. The module uses
the `Swift_SDKROOT` filepath as a hint on where to look for the runtime
libraries and the `dispatch_STATIC` boolean to specify whether it should
find the dynamic library or the static archive.
The stdlib needs to build in Swift-5 mode, and ensure that
`-swift-verion 5` be included in the commandline explicitly. While the
compiler defaults to 5 mode, if it's not included explicitly, it won't
be included in the swift interface, which then means that modules that
import it will influence how the textual interface is processed.
The interface for the stdlib must be processed in the Swift 5 language
mode due to sendability. Set it explicitly to ensure that importing
modules do not change the Swift language mode.
Fixes: rdar://145118843
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.
The names of the variables in `DefaultSettings` should end in `_default`
so that the variable that they are defaulting can be overridden.
Otherwise CMake will just set the value and move on overriding the
setting coming from the commandline/cache file.
The `CMAKE_MT` path does not expand as expected. Add a workaround for
the issue so that we are able to build a dynamically linked version of
the standard library with the new runtimes build.
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.
This will allow us to have multiple parallel installations of swiftCore
with the same DLL name allowing us to side-step the ABI instability
without resorting to SOVERSIONing.
Add an option to enable emitting a stacktrace on calls to `fatalError`.
This is unrelated to the runtime backtracer for diagnosing normal Swift
crashes.
rdar://142440689
In some configurations, libraries are installed under
`<install-prefix>/{libdir}/swift/<platform>/<arch>` and module content
is installed under `<install-prefix>/{libdir}/swift/<platform>`.
This also accounts for the fact that Swift currently looks under
`<install-prefix>/{libdir}/swift_static/**` for the static stdlib
builds.
With swiftlang/swift#78717 we now can extract the platform and
architecture subdirectories required for deploying the files.
Restructure the code when adding this functionality to invoke the
command once and then extract the various fields that we need.
The Swift runtime requires the CMPXCHG16B ISA extension on x86. This is
controlled by the `-mcx16` flag when targeting the CPU baseline that we
use. Add a check and pass along the flag to repair the build.
This is required for the non-Darwin targets as `SWIFT_THREADING_DARWIN`
does not enable any additional code. However, that macro is used in
other places that are not yet integrated. This was identified by
building for Windows.
`defaulted_set` wasn't expanding the default variable, just setting the
value of the variable the name of the variable that should have been
doing the defaulting.
Making a more in-depth pass over the definition macros and flags in
SwiftSource.cmake _add_target_variant_swift_compile_flags.
These are only flags that actually matter for swiftCore though. This
does not include concurrency flags.
Adding vendor-specific extension points to the build system, giving
vendors a place to put their internal settings and defaults, without
having to modify the build directly. This helps reduce the chances of
merge conflicts and public changes breaking internal settings.
The location of the macros are set with `SwiftCore_PRIVATE_MODULE_DIR`,
so vendors can keep their private extensions in a separate location if
desired. Otherwise, it defaults to `cmake/modules/private`, which
intentionally does not exist at this time.
Currently, we have extensions for the default settings and global
settings.
This patch cleans up the handling of WMO-forcing in the workaround file.
`-wmo` is passed in each of the link jobs in the non-CMP0157-enabled
configuration to keep it matching the behavior of the CMP0157-enabled
builds.
This also moves the commentary about num-threads and WMO to the top of
the file to make it clearer what is going on. Ideally the file wouldn't
have to exist, but it does.
The file also contains the target install-name fix that landed in CMake
3.29.8 and CMake 3.30.2, so earlier versions of CMake 3.29 will work
with this build as well.
Fixing some of the comments in DefaultSettings.cmake and
PlatformInfo.cmake.
I haven't added any vendor cache files yet, so the comment doesn't point
anywhere. Also fixing the reference to the location of the clang
resource headers in PlatformInfo.cmake.
Moving the rest of the references to the compiler source directory to
use the `SwiftCore_SWIFTC_SOURCE_DIR` variable instead of
`${PROJECT_SOURCE_DIR}/../../`.
This patch makes it simpler to setup reasonable defaults for a given
platform. The standard library has many knobs for configuration
purposes. This is great for providing cache files to configure specific
builds, but the build system should still generally work if someone runs
a minimal CMake invocation against the build without futzing with
various options.
This patch hooks up the swiftCore library build and gets it installing.
This means that we have library evolution hooked up and vector types.
Building it dynamically found that we had duplicate symbols, so fixed
the swiftDemanglingCR library.
Needed to hook up the availability macros.
The flag configuration is for macOS, so we'll need to go through and
figure out what it should look like for the other platforms too.
Adding stdlib stubs library, which uses gyb and requires knowing about
some of the platform info.
The stubs library pulls in several headers from the compiler repository.
We should probably clean that up, but not right now. I've made a note of
it.
