This is needed for cross-compiling the toolchain to Windows ARM64 on
Windows x64 using Visual Studio which does not permit the NATIVE
sub-build to work properly.
clang/cmark are only needed for the tools, not for the runtime/SDK
overlay. Do not attempt to configure clang and CMark in the case we do
not build the tools. This is needed to enable the standalone standard
library only builds.
The standard library does not depend on the LLVM libraries at runtime. Do not
perform the search for the LLVM configuration when the tools are not being
built. This is needed to permit cross-compiling the standard library standalone
for android on a Linux host without building LLVM and Clang for android.
A typo snuck into the cross-compiling path and due to the machine that it was
tested on hvaing `/bin/llvm-tblgen`, the build succeeded. Correct the typo to
ensure that we use the correct tblgen.
CMake defaults to using a special <package>_DIR for finding packages.
Prefer this to import the CMake package for LLVM/Clang/Swift rather than
custom paths.
CMake defaults to using a special <package>_DIR for finding packages.
Prefer this to import the CMake package for LLVM/Clang/Swift rather than
custom paths.
Include a missing CMake module in a couple of locations that we were
using the function. Simplify a condition to use `MATCHES` rather than
two `STREQUAL`.
This converts the path separators to the CMake way. This is primarily
important for Windows where the path separator is \ rather than /. This
conversion allows the specification of the path in the proper windows
path style.
Attempt to repair the build for the unified swift build. This allows us
to build a single unified toolchain with swift support. In this layout
assume that cmark and clang are peers of LLVM rather than located in
`tools`. Doing so allows a uniform layout of the tree and a simpler
build approach.
The key thing here is that all of the underlying code is exactly the same. I
purposely did not debride anything. This is to ensure that I am not touching too
much and increasing the probability of weird errors from occurring. Thus the
exact same code should be executed... just the routing changed.
Visual Studio's compiler does not accept `-Werror=switch`. Use the equivalent
`-we4062` option instead. Avoid using the `--` separate that clang uses to
identify that the options that follow are files and not options on the Visual
Studio compiler to reduce the unnecessary spew when building on Windows.
When cross-compiling or specifying a custom sysroot and desiring a
hermetic build, many CMake toolchain files will have a custom
CMAKE_FIND_ROOT_PATH and set the CMAKE_FIND_ROOT_PATH_MODE_* variables
to ONLY, meaning packages will only be searched for in the rerooted
directories. We don't want this rerooting to happen when searching for
the LLVM and clang packages though, since we're specifying our search
paths explicitly and excluding search paths from the system, and we
don't want those explicit search paths to be rerooted.
It's standard to set CMAKE_FIND_ROOT_PATH_MODE_PROGRAM to NEVER instead
of ONLY, since you usually want programs to be found for the build
system and not the host system, so the change for the llvm-config search
is not technically required. It doesn't hurt for consistency though, and
I can envision some scenarios in which it might come in handy.
- Re-enable the use of folders with the USE_FOLDER setting. This got
lost a while ago when we stopped including LLVM's top-level
CMakeLists.txt.
- Put a bunch of new targets into folders.
Should not affect the built product and definitely shouldn't affect
anyone not building with Xcode (or MSVC, I guess).
This change broke the Windows builds for all the variants. `-z defs` cannot be
used on all targets, particularly in environments where the stdlib is being
compiled for a foreign host. This needs to be handled more carefully as I
mentioned on the PR itself. In the mean time, revert it to get Windows building
again.
LLVM-style projects like Swift make heavy use of switch statements and
therefore -Werror=switch is very useful during feature development. That
being said, if asserts are disabled, then you're probably not actively
hacking on the project and -Werror (or warnings in general) aren't
helpful.
Swift doesn't produce its own tablegen and by faking out the LLVM CMake infrastructure into thinking it does all of LLVM's build cross compilation support breaks.
With the change in LLVM r305142, CMake will fail if SWIFT_TABLEGEN_TARGET
is not set. When cross-compiling, it could be set differently than
SWIFT_TABLEGEN_EXE but it does not look like Swift supports that yet. For
now, just set it to the same value as SWIFT_TABLEGEN_EXE.
In Xcode builds the library dir variable contains the build configuration in the path, but the exports file doesn't. If we construct the export file path from the build directory instead of the library directory it should all work.
* 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
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.
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).
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
