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