As of CMake 3.25, there are now global variables `LINUX=1`, `ANDROID=1`,
etc. These conflict with expressions that used these names as unquoted
strings in positions where CMake accepts 'variable|string', for example:
- `if(sdk STREQUAL LINUX)` would fail, because `LINUX` is now defined and
expands to 1, where it would previously coerce to a string.
- `if(${sdk} STREQUAL "LINUX")` would fail if `sdk=LINUX`, because the
left-hand side expands twice.
In this patch, I looked for a number of patterns to fix up, sometimes a
little defensively:
- Quoted right-hand side of `STREQUAL` where I was confident it was
intended to be a string literal.
- Removed manual variable expansion on left-hand side of `STREQUAL`,
`MATCHES` and `IN_LIST` where I was confident it was unintended.
Fixes#65028.
This patch goes through and adds zippering and the swift module
dependencies to a bunch of pieces of the swift runtimes. Here's to
hoping I hit everything that needed to be hit. :D
With this patch, I'm seeing the appropriate modules under
lib/swift/maccatalyst, so things seem to be working right.
When SwiftGlibc.h was added in #32404, no cmake code was added to copy it to the
static resources. Copy it along with glibc.modulemap, which references it.
This macro was previously substituted when generating `glibc.modulemap` file during the compiler build. Now Swift detects the location of Glibc dynamically and injects `glibc.modulemap` into it using LLVM VFS. The last usage of `GLIBC_INCLUDE_PATH` was removed in `78c0540b`.
This also removes `SWIFT_SDK_${sdk}_ARCH_${arch}_LIBC_INCLUDE_DIRECTORY` which doesn't have any usages left.
This migrates OpenBSD to use the single-header Glibc modulemap proposed
and implemented in #32404, and necessitates introducing some missing
headers for building Foundation added in #38341.
Additionally, incorporate nullability annotations in SwiftShims per
* add an option to add freestanding to the Darwin platform, so that
to get expected compile behaviours (e.g. setting the install name)
* rework testing configuration to relax assumptions about freestanding
* add a preset to test such configuration (at least for PR testing)
Addresses rdar://85465396
Unfortunately using the convenient "bootstrapping0-all", etc. custom targets does not work.
For some reason it does not cause a dependent file (like libswift's SIL.o) being rebuilt when a depenency (like swift-frontend from the previous bootstrapping stage) changes.
Instead we have to list al library- and executable-targets explicitly.
swiftDarwin and swiftOnoneSupport didn't depend on building the Swift core library.
This was a subtle bug, because the compiler just picked up the module from the SDK instead of the (still building) Swift module.
It only resulted in compiler errors if the SDK swiftinterface was too new to be parsable by the compiler.
* fix a typo which prevented linking the right bootstrapping libs
* build swiftDarwin for bootstrapping
* disable COW checks if built with bootstrapping-with-hostlibs
* Fix two issues with the SwiftGlibc module map.
The issues are:
- Today, some submodules in `SwiftGlibc` fail to provide definitions that
they should contain. As a consequence, Swift fails to import some code
that compiles correctly with standalone Clang. As just one example,
including `signal.h` should make the type `pid_t` available, but it
currently does not.
- `SwiftGlibc` is not compatible with the libc++ module map. Trying to
include libc++ headers in a C++ module imported into Swift results in an
error message about cyclic dependencies.
This change fixes both of these issues by making it so that `SwiftGlibc`
no actually longer defines a module map for the glibc headers but merely makes
all of the symbols from those headers available in a module that can be
imported into Swift. C / Objective-C / C++ code, on the other hand, will now
include the glibc headers texually.
For more context on the two issues and this fix, see this forum
discussion:
https://forums.swift.org/t/problems-with-swiftglibc-and-proposed-fix/37594
This change only modifies `glibc.modulemap.gyb` for the time being but
leaves `bionic.modulemap.gyb` and `libc-openbsd.modulemap.gyb` unchanged. The
intent is to fix these in the same way, but it will be easier to do this
in separate PRs that can be tested individually.
Co-authored-by: zoecarver <z.zoelec2@gmail.com>
Co-authored-by: Marcel Hlopko <hlopko@google.com>
This replaces swiftMSVCRT with swiftCRT. The big difference here is
that the `visualc` module is no longer imported nor exported. The
`visualc` module remains in use for a singular test wrt availability,
but this should effectively remove the need for the `visualc` module.
The difference between the MSVCRT and ucrt module was not well
understood by most. MSVCRT provided ucrt AND visualc, combining pieces
of the old MSVCRT and the newer ucrt. The ucrt module is what you
really wanted most of the time, however, would need to use MSVCRT for
the convenience aliases for type-generic math and the deprecated math
constants.
Unfortunately, we cannot shadow the `ucrt` module and create a Swift SDK
overlay for ucrt as that seems to result in circular dependencies when
processing the `_Concurrency` module.
Although this makes using the C library easier for most people, it has a
more important subtle change: it cleaves the dependency on visualc.
This means that this enables use of Swift without Visual Studio for the
singular purpose of providing 3 header files. Additionally, it removes
the need for the installation of 2 of the 4 support files. This greatly
simplifies the deployment process on Windows.
- deduplicate the logic to compute the resource folder
- install headers and module files in shared and static resource folders
- forward -static flag when calling swiftc with -print-target-info
Commit for CMake and build scripts to recognize OpenBSD. To keep this
commit relatively short, this just deals with the rather simple and
uncontroversial changes to the build system.
Note that OpenBSD calls "x86_64" as "amd64", Since the Swift stdlib will
be put in a subdirectory named after ARCH, to ensure the standard
library is properly found later, we use the native architecture name for
OpenBSD in the build system rather than trying to deal with the
difference the other way around.
Provide a separate modulemap for OpenBSD's libc, rather than try to
continue to overload the modulemap for glibc, since glibc has its own
idiosyncracies.
The build scripts assume Android cross-compilation using the NDK, so avoid
that configuration if building on an Android host. Fix or disable some tests,
and don't install a glibc.modulemap without a native sysroot prefix.
This enables the use of the math defines when building tgmath.swift.
Although not used in the normal branch, this define is necessary to
build the swiftMSVCRT module for TensorFlow which uses the math
constants.
This commit introduces a CMake target for each component, adds install targets
for them, and switches build-script-impl to use the target `install-components`
for installation. Each of the targets for each component depends on each
of the individual targets and outputs that are associated with the
corresponding swift-component.
This is equivalent to what already exists, because right now install rules are
only generated for components that we want to install. Therefore, this commit
should be an NFC.
This is a resubmission (with modifications) of an earlier change. I originally
committed this but there were problems with some installation rules.
This commit introduces a CMake target for each component, adds install targets
for them, and switches build-script-impl to use the target `install-components`
for installation. Each of the targets for each component depends on each
of the individual targets and outputs that are associated with the
corresponding swift-component.
This is equivalent to what already exists, because right now install rules are
only generated for components that we want to install. Therefore, this commit
should be an NFC.
This makes it more explicit what the install component of a target
library is if you don't see one (and its marked as IS_SDK_OVERLAY).
Explicit in this case makes more sense, as you don't have to rely on
knowledge of how `add_swift_target_library` is implemented to understand
what component is used to install the target.
There are situations where you want to build against a libc that is out
of tree or that is not the system libc (Or for cross build scenarios).
This is a change for passing the -sdk and include paths for things like
this.
Rather than hardcoding the paths to /usr/include, allow the user to set
the path to their libc headers. This is particularly important for
environments which may not use the traditional layout (e.g. exherbo) or
for builds which wish to build against an out-of-tree, non-system
installed libc for a Unix target which does not match the host system
(i.e. foreign cross-compilation).
This splits out the bionic modulemap from the glibc modulemap. They are
sufficiently different that the duplication is worth it. Furthermore,
it will enable properly identifying the libc on android. Once fully
detangled, this will enable the use of bionic on non-android platforms.
CMake supports the notion of installation components. Right now we have some
custom code for supporting swift components. I think that for installation
purposes, it would be nice to use the CMake component system.
This should be a non-functional change. We should still only be generating
install rules for targets and files in components we want to install, and we
still use the install ninja target to install everything.
Magic symbols of the form $ld$install_name$os9.0$@rpath/libswiftCore.dylib tell the linker to use that install name when targeting that OS version. Use these symbols to specify an @rpath install name for all back-deployment libraries when targeting watchOS 2.0-5.1, iOS 7.0-12.1, and macOS 10.9-10.14.
rdar://problem/45027809
This avoids us having to pattern match every source file which should
help speed up the CMake generation. A secondary optimization is
possible with CMake 3.14 which has the ability to remove the last
extension component without having to resort to regular expressions. It
also helps easily identify the GYB'ed sources.
They're all the same anyway, and no longer even need to be compiled,
just copied in as text.
And drastically simplify how we "generate" them. Instead of attaching
their build jobs to the appropriate overlays, if present, "just" have
one job to copy them all and attach it to the Darwin overlay. That's
what we do for the overlay shim headers, and it's good enough.
(Eventually we want to get out of the business of shipping them
altogether.)
This does have the same flaw as the shim headers: if you /just/ change
API notes, the corresponding overlay does not get rebuilt. You have to
touch that too. But in practice that'll happen most of the time
anyway.
Part of rdar://problem/43545560
The key thing here is that all of the underlying code is exactly the same. I
purposely did not debride anything. This is to ensure that I am not touching too
much and increasing the probability of weird errors from occurring. Thus the
exact same code should be executed... just the routing changed.
ndk14 introduced "unified headers" which merged the headers for all
different API versions into one directory which effectively split the
"SWIFT_SDK_ANDROID_ARCH_${ARCH}_PATH" into two different directories.
Add include and library specific paths to various compilation and link
invocations across the Swift project to account for this change. Remove
some broken sysroot/sdk specific settings.
