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)
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.
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 is loaded by the CMake package configuration so that you can add
cross-package dependencies. Adjust the path so that the lookup succeeds
on all targets.
Add cmake cache for enabling sccache while building with the new runtime
build when sccache is available.
To build with sccache, pass the `sccache.cmake`
```
cmake \
-B build \
-S Runtime/Core \
-C Runtimes/Core/cmake/cache/sccache.cmake
```
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.
Optimization remarks were always emitted on Darwin but not on the other
platforms and were forced to use the bitstream format. Adding a flag to
enable or disable them as desired and specify the desired output format.
Fixes: https://github.com/swiftlang/swift/issues/79279
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.
The main goal for now is to have this building, with little
concern about matching the build flags used currently.
Keep it disabled by default on Apple platforms.
Addresses rdar://143151393
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.
