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