The runtime mixes `swift` and `swift_static` SDK layouts when building
Swift code on Android. The overlay is always referenced in `swift` and
never from `swift_static`. Adjust the layout to match the driver.
...instead of platforms.
Notable changes/flags:
* Append to variables controlling paths and names, to allow for user
configuration
* add `SwiftCore_USE_STATIC_LIBS` to generate static archives
* use PlatformInfo variables to get the platform and arch subfolders
(where appropriate)
* add include guards to ensure PlatformInfo and FindSwiftCore are
included once in a project
* search for the appropriate static or import library under Windows
Addresses rdar://152838903
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.
Adjust the StringProcessing module to follow the defaults of SwiftCore
with regards to generic metadata prespecialization and the library
evolution modes.
Add `SwiftSynchronization_ SINGLE_THREADED_MODE` flag to use
empty mutex definition for certain apple platforms. This brings
Synchronization in line with the current build systems functionality
We will revisit this in the future to determine if we can add a mutex
definition for all Darwin platforms
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
WIP to add more overloads to optimize SIMD codegen on concrete types.
Here we do:
- init(repeating:)
- init(lowHalf:highHalf:)
These are always inlined, even in debug, since LLVM knows how to lower
them to one or two instructions on the targets that we care about.
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
This matches the case that we use in the Runtimes build system, so we
rely the exported target instead of adding `-lswiftCore`.
Addresses rdar://151700669
This allows compaction into swiftCore when building mirroring the
beahviour of the old build system. This matters solely when building
with a static library distribution of swiftCore where you would
previously need to explicitly link against the swiftCommandLineSupport
library when building with the new build system.
Disable CMP0157 with the old driver as this breaks on Windows. Adjust
the Windows platform ID spelling to repair the Windows build. Take the
opportunity to re-order some of the structure so that it is similar to
the other modules.
Update the `find_package` to mark `SwiftCore` as `REQUIRED`. This also
re-orders some of the declarations to make the CMakeLists.txt layout
more uniform across the projects.
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.
We would fail to build the runtime with the new build with command line
support and a shared runtime. The reason for this was that
CommandLineSupport did not properly build against the headers and
attempted to import a locally defined symbol. Correct the build by
indicating that this library is compacted into the runtime.
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.
