Before #82571, we would generate a binary swiftmodule file at `<build
folder>/<module>.swiftmodule`, while now in the same location we
generate a directory.
Trying an incremental run on top of a build folder generated with the
old logic will fail during configuration with an error similar to
```
CMake Error at .../Supplemental/cmake/modules/EmitSwiftInterface.cmake:21 (file):
file failed to create directory:
.../StringProcessing-build/_RegexParser/_RegexParser.swiftmodule
because: File exists
```
To reduce churn in CI and at desk, delete such remnant from the previous
logic.
Addresses rdar://155466197
Implements a similar caching mechanism to what CMake uses for detecting
the compiler. The file is created based on the computed values and
allows us to avoid calling the compiler if we aren't going to extract
out any platform info.
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 reflection enabled as swift-collections uses this which is
required for Foundation. Adjust the defaults to allow building
Foundation for Android again.
These need to be defined always; we'll set them to "unknown" and "none"
respectively if they end up being something we don't understand.
rdar://150966361
Add catalyst support for SwiftStdlibCurrentOS.
Also, set a minimum deployment target when building Concurrency;
this stops the build failing when we're trying to build on older
systems where Concurrency didn't really exist yet.
rdar://150966361
Enable command line support, library evolution, vector types, file
system support, runtime function counters, and optimization remark
emission. This brings the windows runtime configuration and Darwin
to parity.
CommandLine support builds on all platforms at this time. There is no
need to have a default disabling it anymore. Setting the default option
to enable it on all platforms without condition.
This is part of the development component for the module and is part of
the interface definition. This content is consumed by the user during
development.
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
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.
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.
