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.
Instead of overwriting all of the paths for the other build configurations with
the one that LLVM selected, I was resetting the path for LLVM's build
configuration over and over again. = /.
This fixes the issue.
Currently when we build with bitcode, we use the liblto that we just built,
despite the fact that we just compiled the runtime with the host clang. Really,
we should be consistent.
In the short term to unblock LTO (which wants to use the host liblto), provide
an option to use the host liblto but leave it off so that the normal behavior is
preserved.
As an additional fix, this moves the include of SwiftXcodeSupport to the one
place where its functionality is used, AddSwift.cmake. Keeping the include in
./CMakeLists.txt makes it seem like the functionality is needed there (when it
is not).
In a subsequent commit, I am going to refactor the xcode support I have been
adding to SwiftSharedCMakeConfig into this file and have SwiftSharedCMakeConfig
import it.
Introduce two new aliasees `ALL_POSIX_PLATFORMS` and `ALL_APPLE_PLATFORMS`. The
latter expands to iOS, tvOS, watchOS, macOS and if relevant, the simulators.
The former expands to the same list as `ALL_APPLE_PLATFORMS` as well as Linux
and FreeBSD.
If we compile LLVM for <CONFIG> in build-script with Xcode as our generator,
LLVMExports.cmake will have specific IMPORTED_*_<CONFIG> variables set for all
of our targets. These variables are what we really want to splat across all
Swift Xcode build configurations.
This patch rips out the old code that determined the actual location and instead
just grabs the IMPORTED_*_<CONFIG> variables and splats it accordingly.
2633a0f3 expanded SWIFT_MODULE_DEPENDS_* to treat Linux and FreeBSD
separately. Android needs the same treatment as Linux, so expand the
Linux check to include Android as well. These changes fix an Android
build error, in which Glibc was not linked to private stdlib libraries
that relied upon it.
When the standard library is built dynamically on COFF targets, the public
interfaces must be decorated in order to generate a proper DLL which can be
confused by the dependent libraries. When the exported interface is used, it
must be indirectly addressed. This can be done manually in code or the MS
extension of `__declspec(dllimport)` may be used to indicate to the compiler
that this symbol be addressed indirectly. This permits building more pieces of
the standard library dynamically on Windows.
Eliminates a warning when building lldb.
It looks like lldb is still able to find the right library. But doing it this
way is guaranteed to be correct (eliminating future bugs is good).
It is better to have the top level CMake file only consist of includes and
settings, rather than have it include business logic like this.
Should be NFC.
_OBJECT_FORMAT was added recentlyish for all the SDKs. Use that property rather
than enumerating all the ELFish targets. This ensures that the code path is
correct if another ELFish target is ported to.
Now that we have the full dependency information from LLVM/Clang, this is no
longer necessary. We will just do the *right* thing.
Additionally, since we were passing these libraries as absolute paths, cmake was
always passing through all of the given libraries even if CMake had already
added them to the link line in its non-absolute form. It is not clear to me how
if all linkers would be smart about this.
Regardless, now we just translate components to libraries and continue on our
merry way. In the future, we can even remove the llvm-build code period by just
specifying LLVM dependencies directly via LINK_LIBRARIES instead of having to do
anything with COMPONENT_DEPENDS.
But that is for a future commit.
Normally when building in Xcode, Xcode will assume that LLVM/Clang use the same
configuration as Swift and will try to pull in the sources from that
configuration's build directory.
This is incorrect when we are compiling a Release LLVM with a Debug Swift. This
commit uses our escaping functionality from 0a48857 and the new imported targets
to fix this issue.
rdar://27062396
In order to support swapping build types without reconfiguring, Swift's CMake
generated Xcode project has one directory for each cmake build type. This
behavior is implemented by placing in variables for Xcode to expand at build
time. This causes issues with our build, namely that our cmake scripts like to
"poke" around the LLVM build directory at configure time. Since the xcode
variables from the commit title are not expanded, failures occur since the
unexpanded paths do not exist.
This patch fixes this problem by expanding out those variables at configure time
from specific LLVM paths. This is essentially tieing LLVM to the specific
build-script build mode used. This is reasonable since we do not support
building in Xcode for configurations that were not selected at build-script
time.
rdar://27062396
