Even with unified build, llvm is not always the top-level project but it
can be a part of a larger build. (e.g. [^1]) In that case,
`CMAKE_BINARY_DIR` is not the binary directory of llvm but the binary
directory of the top-level project. This patch fixes the issue by using
`LLVM_BINARY_DIR` instead.
[^1]: 9b4b907079/extensions/cxx_debugging/CMakeLists.txt (L105)
This was quite brittle and has now been superseded
by swift-xcodegen. Remove the CMake/build-script
logic for it, leaving the option behind to inform
users to switch to using xcodegen instead.
This silences a warning that the MSVC compiler emits about unknown
pragmas. This helps clear up the build a small amount so real issues do
not get hidden.
For C/CXX targets, sanitizer options are set by 'CMAKE_{C|CXX}_FLAGS' in
HandleLLVMComfig.cmake. However for Swift targets, they are set for each
target. That caused some mismatch issues. Instead set them globally for
Swift targets too.
rdar://142516855
If one is building unified and also cross-compiling (for example
building from Linux x86_64 to Linux aarch64), these variables which are
normally set in the cache pointing to a native toolchain are overwritten
unconditionally pointing to the `CMAKE_BINARY_DIR`, which can be
incompatible with the build machine.
The value of `SWIFT_NATIVE_CLANG_TOOLS_PATH` is eventually passed to the Swift
compiler as `-tools-directory`, which the new `swift-driver` actually
seems to use to find `swiftc`. When the `swift-driver` tries to use the
incompatible `swiftc`, it returns with a very unhelpful "error: failed to
retrieve frontend target info".
Avoiding overwriting the variables when cross-compiling lets the build
system use the variables provided in the cache, which point to correct
binaries for the build machine.
Extricate cmark from the unified build system. This is preparatory work
to support building CMark GFM with dynamic linkage for sharing it across
swift-markdown and the compiler. It also simplifies the build logic for
the unified build.
ClangConfig sets `CLANG_INCLUDE_DIRS` and Swift build system uses that
variable in a couple of places. Without this, several of the include
directories for Clang might not be added to different parts of the
compiler, like when using SwiftSourceSupport files. Before these
changes, headers like `clang/CAS/CASOptions.h` were not being found.
`CMAKE_CXX_FLAGS` are user controlled and should not be touched by the
build system [1]. Use global `add_compile_options` and
`add_compile_definitions` to control the flags for the targets.
[1] https://cmake.org/cmake/help/book/mastering-cmake/
Conditionalise the inclusion of directory paths. If the include
directory is empty, CMake will raise an error. This allows us to disable
larger portions of the Swift build to speed up some of the build tool
configuration phase and prepares for consuming CMark GFM as a CMake
project.
Introduce two modes of bridging:
* inline mode: this is basically how it worked so far. Using full C++ interop which allows bridging functions to be inlined.
* pure mode: bridging functions are not inlined but compiled in a cpp file. This allows to reduce the C++ interop requirements to a minimum. No std/llvm/swift headers are imported.
This change requires a major refactoring of bridging sources. The implementation of bridging functions go to two separate files: SILBridgingImpl.h and OptimizerBridgingImpl.h.
Depending on the mode, those files are either included in the corresponding header files (inline mode), or included in the c++ file (pure mode).
The mode can be selected with the BRIDGING_MODE cmake variable. By default it is set to the inline mode (= existing behavior). The pure mode is only selected in certain configurations to work around C++ interop issues:
* In debug builds, to workaround a problem with LLDB's `po` command (rdar://115770255).
* On windows to workaround a build problem.
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.
