The availability flags keep increasing the number of characters on the
command line overflowing the maximum character length on Windows and
making the commands harder to read. This patch moves the generated
arguments into a separate response file so that they can continue to
grow without running into argument length limitations.
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.
(cherry picked from commit 0100104ff7)
This adjusts the default settings for the Windows build of the Swift
runtime to include reflection and to re-order them to match the Darwin
configuration to make it easier to identify differences.
This adjusts the spelling for the architecture specifier for the Windows
compilers. Take the opportunity to further restrict the compiler check
to micro-optimize the CMake configure phase.
Extracting experimental feature flags into a separate file so that we
can add Allan as a code owner of just that file. He has to deal with
breakage when folks remove these flags improperly.
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.
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.
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.
