Mostly this just means adding `Musl` as a module dependency of various
things and making sure that we build things for `swift_static` even
if `SWIFT_BUILD_STATIC_STDLIB` isn't enabled.
There's also a slight difference in the declaration of `memcmp()`;
musl's declaration is more like the one we have on Darwin.
rdar://123508245
This was used for the swift-reflection-test tool. Instead of using fat
binaries, use the target binary itself. This simplifies the build logic
as well as paves the road to sub-builds for each target rather than a
monolithic build as we have today.
Originally, the swift-reflection-test was a host tool that linked
against the target libraries since it was testing the target layout.
Now that the tool has been split into a host and target component
(5ea5bb06a3) and we have target and host
libraries that we can link against appropriately, we do not need to link
against the FAT binary. Since there was exactly one use of this
functionality, switching that from fat linking to regular linking allows
us to remove this functionality entirely. Switch to regular linking and
remove the option.
This adds an explicit version of the SwiftRemoteMirror library for use
in the tools that comprise the toolchain. This is a separate build from
the target specific builds of the library even though we may be building
the runtime for the (same) host.
If one thinks about it, swift's build has two sections: a runtime or target
section (i.e. ./stdlib) and a host section (everything
else). swift-reflection-test is an abberation from that pattern since it is
built for target platforms but is in the section of host tools.
In this commit, I move it into ./stdlib. Beyond being a bitter location
conceptually this will additionally allow me to avoid a dependency cycle in
between the compiler and the stdlib build.
After this, there is only one more target in the compiler code: swift-lang. From
talking with Xi Ge, we can move that into its own separate project as a
package. Once that is done, I will not have any more cycles.
