There were three different issues going on here, all of these were triggered by https://github.com/apple/swift/pull/61618 which stared including `AST/AnyFunctionRef.h` from the ASTBridging modulemap
- We did not find the clang include dirs because the unified build that build-tooling-libs is using does not import ClangConfig, setting `CLANG_INCLUDE_DIRS` in `swift_common_unified_build_config` fixed this problem.
- Some of the headers in `swift-ast-generated-headers` import generated headers from clang that might not have been created yet. Making `swift-ast-generated-headers` depend on the clang generated headers fixes this problem. This just lowers the dependency because `swiftAST` depends on `swift-ast-generated-headers`
- If a Swift compiler from Xcode is used, the SwiftShims don’t live next to the compiler but in the SDK. Adding the SDKs lib to the include paths fixes this problem
Clang and Swift both support this so we can do this until the actual fix lands
in a host toolchain to unblock ErikE.
The specific problem is the swift driver should just push tbd files through to
the linker, but it treats it as an input file. I am going to be putting a fix
into 5.5. This patch in the mean time filters out the tbd files in cmake. This
is a temporary fix.
I also had to add direct dependencies from swift-refactor and
libSwiftSyntaxParser on LLVMSupport to ensure that the right linker flags get to
them.
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
