Use the associated library name for the `CFBundleIdentifier` within the
plist. This will prevent cases where we have projects with multiple
targets referencing the project name itself (i.e swiftSwiftOnoneSupport
had it's bundle name set to SwiftCore)
To make this work:
* expose SwiftCMakeConfig.h from the Core build
system, to support scenarios in which the downstream Distributed build
is leveraging the config files generated by CMake itself.
* adjust how SwiftShims is defined in `FindSwiftCore.cmake`, so that the
shims are found from C++ and that we don't get redefinition errors
when multiple module maps are in the search paths.
Fixes#83449
Addresses rdar://149241603, rdar://157165530
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.
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.
These libraries use C++ as the linker language which will prevent
`CMAKE_STATIC_LIBRARY_PREFIX_Swift` from impacting them. Wire this
property to the target manually so that it takes effect. This is
primarily meant to support Windows, where we use a non-standard library
prefix for static libraries mirroring the behaviour of the language
runtimes (i.e. ucrt, vcruntime, msvcrt).
Explicit module builds help prevent the dependency scanner from getting
lost and attempting to pull the SwiftShims module from the resource
directory, existing SDK, and the just-built standard library.
They aren't part of the library interface, but make it possible to build
the runtime libraries without seeing duplicate shims. Moving the flag to
a top-level compile command.
This removes the workaround for the exporting of the registrar and
enables proper dependency tracking across projects (primarily geared
towards the Overlay).
swiftCore and swift_Concurrency libraries use C++ and Swift. The C++
does not use the Swift C++ interop. Swift driver only uses clang++ to
link when building in C++ interop mode and there currently isn't a flag
to change that. Since we're explicitly linking the runtime registration
when necessary and do not need compatibility libraries, it is safe to
use clang++ as the linker directly, instead of going through swiftc.
In versions of CMake older than 3.29, Swift is always used as a linker
and has no compile stage. By using clang++ as the linker, we require the
split build model (CMP0157), so we cannot allow versions of CMake older
than 3.29.
Explicitly add the path to the Swift module to the interface include
directories. It is unclear why this is not propagating implicitly from
the module definition. For now, this ensures that the client is able to
load the standard library.
This re-organises the file a small amount to put the source listing and
additions together. Subsequently, apply compile definitions, options,
and then link libraries and finally options
`swiftrtT.obj` should be used for statically linking the standard
library (or within the standard library itself). For the other modules,
we need to differentiate between `swiftrt.obj` and `swiftrtT.obj`. This
fixes that oversight. This was not caught by the CI builds as we do not
currently build both the static and dynamic variants of the new
runtimes.
We introduce a new macro called #SwiftSettings that can be used in conjunction
with a new stdlib type called SwiftSetting to control the default isolation at
the file level. It overrides the current default isolation whether it is the
current nonisolated state or main actor (when -enable-experimental-feature
UnspecifiedMeansMainActorIsolated is set).
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.
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.
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.
Use the static module constructor for swiftCore on Windows as the
runtime functions are internal to the module. This fixes the last linker
warning that we see with the standard library build when building
dynamically. More importantly, this allows building swiftCore as a DLL
with the new build system on Windows as we now treat any linker warnings
as errors.
These libraries are now implicitly explicitly linked. The source files
include `#pragma comment(lib, ...)` to include the autolink directives
to properly handle the dependency propagation to ensure static linking
is sufficiently closed.
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.
These set of Swift flags are applied to all runtime libraries that are
built. Hoist them to the top-level to spell them once and to keep all
the libraries in sync.
