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.
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.
