This reverts commit 10506e00c0.
There are dylibs in lib/swift/macosx/x86_64/ and lib/swift/macosx/, and
with this patch the dylibs in the latter path don't get updated when the
code changes and are stale.
I'm not sure exactly how to correct this patch so let's just try again
when it updates both sets of dylibs.
rdar://28660201
The CMake variable `APPLE` is set to true when building on a macOS
host, which means that logic to include linker flags for application
extensions, etc., will be enabled on a macOS host. That is, they will
be enabled even when cross-compiling the standard library to a
non-Apple platform, such as Android.
Instead of using `APPLE` to check the host OS, check whether the target
is an Apple platform.
When compiling the Swift standard library for Android on Linux, the
target prefixes and suffixes for static and shared libraries happen to
be the same for both platforms. When using a macOS host to compile,
however, the suffixes are different, causing build errors.
Explicitly set the prefixes and suffixes to prevent errors when
building on macOS.
Checking CMAKE_SYSTEM_NAME to append Darwin-specific flags happens to
work when cross-compiling from one Darwinian system to another -- like
using a macOS host to build the standard library for iOS. It doesn't
work, however, when cross-compiling from macOS to Android, for example.
Instead of checking the host system name, check whether the SDK target
is Darwinian.
Swift's CMake build system creates "fat" binaries for Swift libraries,
so long as the host machine used to compile the libraries is a macOS
machine. However, when a non-Darwin target, such as Android, is being
compiled on a macOS host, this doesn't work. Instead, only add lipo
targets if the *target* is Darwin.
Add a function to set library target prefixes and suffixes. When new
targets require setting these prefixes/suffixes, contributors will be
able to modify this one function. NFC.
* Ensure LLVM_CMAKE_DIR is always set so it can be used
* Use LLVM_CMAKE_DIR instead of searching the module paths
* Label parameters of cmake_parse_arguments in comments
Enable CMake policy CMP0057, which allows `if()` statements to use the `IN_LIST`
operator. In addition, simplify several `if()` statements that used the
`list(FIND ...)` operation instead.
CMake's ninja generator doesn't apply POST_BUILD steps to phony targets, instead in creates standalone CUSTOM_COMMAND actions for them. The generated CUSTOM_COMMANDS then end up running always because they don't have properly specified dependencies.
This patch changes the code sign step on the lipo commands from being POST_BUILD commands to being standalone commands with properly specified inputs and outputs. It works by appending "-unsigned" to the name of the lipo target and the lipo output on Darwin build and replacing the lipo target with a target that wraps the code sign command.
With this patch re-running ninja on an already built build directory no longer results in re-codesigning all the stdlib dylibs.
The problem here is a bit complicated. The symlink_clang_headers target creates two symlinks to clang's headers, one under the build directory at lib/swift/clang, and the other under a temporary path.
The one under the temporary path is a bad symlink, and it is only created during the build so that it can be installed. It isn't actually used by the build. Ninja treats the bad symlink as a non-existing file, and since the build rule that creates it has the restat property on it this results in the commands to symlink the clang headers directory running over and over and over again during the build.
This patch prevents that by not generating the bad symlink during the build. Instead we generate it at install time using the LLVMInstallSymlink script that is vended as part of LLVM's distribution.
When building non-standalone and using the in-tree clang all TARGET_LIBRARIES should depend on clang. This ensures clang is built before the build tries to use it.
The main action here is to sink the creation of the installation rule for all of
the swift host tools into this API. In a latter commit, I will use this API to
create include and build rules for add_swift_host_tool.
We also validate that each one of the given components sets are actually sets
and in addition are disjoint from each other.
In order to make sure that this is a NFC change, add all components to all 3
variables. This ensures that we preserve normal behavior of generating cmake
targets for all components and building all components by default even when
nothing is passed in to be installed.
This will remove the restriction that overlays always need to have a source
file matching the name of the framework, at the "cost" of standardizing the
"swiftFoo" convention for libraries with a module named "Foo". (Until
someone exposes the MODULE_NAME setting at the add_swift_library level.)
If this passes all tests, a follow-up commit will adjust the names of
some of the source files in stdlib/.
rdar://problem/17535693
Now that I am going to be adding an IN_SWIFT_COMPONENT argument, I need to do
this to distinguish the concepts of an LLVM_COMPONENT and a SWIFT_COMPONENT.
This is a flexible way to assert that a binary operation succeeds. For
instance to precondition equality:
precondition(EQUAL FOO BAR)
or string equality:
precondition(STREQUALS FOO BAR)
Since cmake is so loosely typed, it is really important that we
precondition as much as possible to ensure sane behavior.
The contents of that .cmake file are cmake utility functions. Move them into
SwiftUtils.cmake, a file that contains cmake utility functions. This is just a
quick cleanup.
In the next little bit I am going to be creating a more complex components
system. In order to help with this, I am renaming SwiftInstallComponents =>
SwiftComponents.cmake to reflect the broader purpose.
In LLVM, the convention is that *_INCLUDE_* means that cmake will generate
targets but says nothing about whether or not something will be built by default
or not. This means that as far as cmake is concerned, those targets do not
exist.
On the other hand, *_BUILD_* determines whether or not a class of things is a
dependency of the "all" target. Of course this implies that *_BUILD_* implies
that *_INCLUDE_* must be set to TRUE.
Currently SWIFT_BUILD_TOOLS is implemented like a *_INCLUDE_* option, so change
its name to SWIFT_INCLUDE_TOOLS.
This adds the swiftMSVCRT module which is similar in spirit to swiftGlibc and
swiftDarwin, exposing the Microsoft C Runtime library to swift. Furthermore,
disable pieces of the standard library which are not immediately trivially
portable to Windows. A lot of this functionality can still be implemented and
exposed to the user, however, this is the quickest means to a PoC for native
windows support.
As a temporary solution, add a -DCYGWIN flag to indicate that we are building
for the cygwin windows target. This allows us to continue supporting the cygwin
environment whilst making the windows port work natively against the windows
environment (msvc). Eventually, that will hopefully be replaced with an
environment check in swift.
