Add an option which the user can specify to switch to the lld linker. Although
this linker is still nascent, it is interesting to permit linking with this. It
is also an alternative to the BFD linker for COFF targets. It will allow for a
cross-compilation story for Windows on non-Windows targets.
This is the only site which allowed you to accidentally accept gold for targets
which are not ELFish. For the time being, we can only add unit tests for the
host variant, so use the `SWIFT_HOST_VARIANT_SDK` to determine the target file
format. This will make supporting cross-compiling to non-ELFish targets
simpler.
This allows us to cross-compile the standard library to foreign targets on a
single host. The ICU dependencies can be specified on the command line on a
per-target basis. If one is not specified, we fall back to the default search
path and use that for the other targets.
Special thanks to Dimitri Gribenko for the various hints in getting this wired
up.
LLVM already provides these directories via the LLVMConfig.cmake variable
LLVM_INCLUDE_DIRS, which we are already using to import those directories.
Thus this work is and even worse gives the illusion that we are not delegating
the computation of LLVM's include paths to LLVM (which is really what we are
doing and should be doing).
rdar://26154980
Setting this value is equivalent to setting:
include_directories(${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_CURRENT_SOURCE_DIR})
in all subdirectories. Since these are all macros, this means that we are adding to the configuration
path the root swift directory. There is no reason to do this and will result in
confusion/bugs in the future.
rdar://26154980
This is apart of a series of patches that separates configuration of
llvm/clang/cmark in swift_common_standalone_build_config. Right now each project
has configuration occurring in a mixed up way. By refactoring it becomes much
easier to read the code.
rdar://26154980
This eliminates us setting an LLVM_ prefixed variable in a situation where there is
a viable alternative.
We want to eliminate as many of these as possible since they can cause conflicts
with variables set in LLVMConfig.cmake.
I also added some convenience tablegen functions in AddSwiftTableGen.cmake and
changed all tblgen users to use that instead.
rdar://26154980
This fixes part of the Xcode build by allowing us to avoid having to use cmake
variables with an unexpanded CMAKE_CFG_INTDIR.
Since those variables are not expanded, they point to a non-existant path like:
.../$(CONFIGURATION)$(...)/lib
So finding tablegen fails. In the cross compile case, we still try to find the
native tablegen.
rdar://26154980
This splits the `--build-swift-stdlib` and `--build-swift-sdk-overlay`
arguments into `dynamic` and `static` variants, which makes the
following build command possible:
```
utils/build-script -- \
--build-swift-dynamic-stdlib=0 --build-swift-dynamic-sdk-overlay=0 \
--build-swift-static-stdlib=1 --build-swift-static-sdk-overlay=0
```
This command produces *only* static libraries for the stdlib, and no
SDK overlay libraries at all. Many other finely-grained build options
are now possible.
There are a couple of things going on in this patch. Lets consider first the
crosscompiling case.
In the cross compiling case, we were already setting LLVM_TOOLS_BINARY_DIR to
the binary dir of the just compiled LLVM (not the native LLVM/clang). This is
exactly what using LLVMConfig.cmake from that just compiled LLVM will set
LLVM_TOOLS_BINARY_DIR.
In the non-cross compiling case, we originally grabbed LLVM_TOOLS_BINARY_DIR
from llvm-config and then used that value to set the NATIVE llvm/clang paths.
rdar://26154980
This was added some time ago in case we want to build clang separate from llvm
just like we do swift. We do not actually support that though.
Currently, this just results in the main llvm binary directory being added for a
second time to the link path (i.e. this work iw asted). Thus just remove the
line but leave in a *NOTE* to deliver the message that this is where the clang
link path in such a case would need to go.
This variable was added in 2015 to set a value that was needed given upstream
changes. In Feb 2016, we started importing LLVMConfig.cmake. LLVMConfig.cmake
provides this value for us. Thus we can remove the dead variable.
rdar://26154980
This bug was in tree before I began to make my changes. I uncovered the bug when
I was thinking about whether or not this line of code was dead and thus looked
at how it was used.
rdar://26154980
Previously in order to support cross-compiling, we were setting these variables
in build-script. Now that we are using LLVMConfig.cmake, passing in these values
are no longer necessary. As an added benefit, Swift when not cross compiling,
does not need to set these variables anyways.
rdar://26154980
Before this patch, we would always set ${product}_PATH_TO_LLVM_{SOURCE,BUILD} to
a value taken from llvm-config. But, turns out we had generated llvm-config
using these values. Thus llvm-config is just giving us back values we already
have.
This commit changes these variables to be precondition variables and doesn't
cause them to be reset.
rdar://26154980
The Android NDK r12 release appends a ".x" to the libgcc directory;
it is now:
```
android-ndk-r12/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/lib/gcc/arm-linux-androideabi/4.9.x
```
Update the linker path for the Android build to accomodate this change.
gold only supports ELF. This adds two new helper functions
(is_windows_based_sdk and is_elfish_sdk) to ensure that we dont try to use gold
on non-ELF targets. This comes up when trying to setup cross-compilation for
the standard library for Windows.
The ELF check is implemented as the negation of Darwin (which uses MachO) and
Windows (which uses COFF). The reason for this is that there are additional
targets which also use ELF. Rather than enumerating the larger set, enumerate
the smaller set (windows) and use the negation.
Create a helper function to determine if we are targeting a Darwin SDK or not.
The repetition is error-prone and verbose. Simplify by adding a checking
function. NFC.
Use the SWIFTLIB_SINGLE_SDK variable rather than the CMAKE_BUILD_SYSTEM variable
to determine the target type. This allows us to use the logic for adding
libraries for foreign OSes on a build host. This is needed to pave the road to
cross-crompiling the standard library for different targets.
The use of `-isysroot` is a Darwin specific behaviour. It is used to switch to
a platform SDK, however, other targets use the `--sysroot` flag. Windows uses a
custom mechanism which is a set of system header paths.
llvm/Support/Compiler.h recently grew a dependency on llvm-config.h. This
pointed out that we were not including the path to the generated header
directory in the build output. Ensure that we have the corresponding -I.
As a first step to allowing the build script to build *only*
static library versions of the stdlib, change `add_swift_library`
such that callers must pass in `SHARED`, `STATIC`, or `OBJECT_LIBRARY`.
Ideally, only these flags would be used to determine whether to
build shared, static, or object libraries, but that is not currently
the case -- `add_swift_library` also checks whether the library
`IS_STDLIB` before performing certain additional actions. This will be
cleaned up in a future commit.
HOST_LIBRARY is supposed to mean "no matter what the defaults say, also build
this library for the host". FORCE_BUILD_FOR_HOST_SDK is a less confusing name.
At some point in the future, we may consider using LTO on the runtime/standard
library, but right now is not that time. We are just trying to use LTO to
improve the compile time performance of the compiler itself.
rdar://24717107
This will allow control on the outside of these calls on whether or not LTO is
enabled. This is necessary for turning off LTO on target libraries.
rdar://24717107
*NOTE* We are still passing this variable into LLVM. Just not into Swift anymore.
I originally passed in the variable -DLLVM_ENABLE_LTO=YES to Swift's cmake to
ensure that the Swift unittests were compiled with lto. That was the wrong
fix.
The reason why is that if -DLLVM_ENABLE_LTO is set to YES then HandleLLVMOptions
in llvm will append -flto to both CMAKE_C_FLAGS and CMAKE_CXX_FLAGS implying
that -flto can not be disabled selectively. This ability to disable flto
selectively is something that we need in order to lto host libraries, but not
lto target libraries.
Thus in this commit, we no longer pass in -DLLVM_ENABLE_LTO=YES to swift's cmake
invocation. Instead we apply the lto flag to the unittest target ourselves in
add_swift_unittest.
rdar://24717107
