Instead of letting CMake set RPATH of the test executables, use
INSTALL_RPATH and BUILD_WITH_INSTALL_RPATH just like other executable
and shared libraries.
Previously when a swift module link with exported swift-syntax targets e.g.
'SwiftSyntax::SwiftParser', the libraries in earlyswiftsyntax were used
instead of the copied libraries in the swift build directory. That
wasn't ideal.
This wires up the new macro properly into the build machinery to ensure
that the `distribution` target properly builds and installs the
dependencies. This fixes the missing `swift-plugin-server` on Windows.
Account for import libraries and the associated layout difference on
platforms (e.g. DLLs are placed in `bin`). This is required to enable
building the macro path on Windows.
`:` is not a valid file system character but is used to namespace the
imported targets. This is then used to create the stamp file. Sanitize
the name prior to use as a stamp file name.
"Support Macros in Linux" patches was inconsistent with checking
platforms. Some only checked 'LINUX' but some matches
'LINUX|ANDROID|OPENBSD|FREEBSD'. Although I don't have tested other
platoforms than Linux at all, there's no reason to limit it to Linux.
So use the consistent check to match 'LINUX|ANDROID|OPENBSD|FREEBSD'
swift-compatibility-symbols, swift-def-to-strings-converter,
and swift-serialize-diagnostics don't use any Swift modules. But when
SWIFT_SWIFT_PARSER was enabled, they are linked with swiftCore. But
these binaries can be executed before the runtime is being built.
We need to stop them linking with swiftCore.
In Linux. Instead of setting temporary "fallback" RUNPATH, Set
LD_LIBRARY_PATH to builder's runtime when building standard library.
So we don't need to strip the temporary RUNPATH when installing.
For compiling codes required for macro support, we now need swiftc
compiler in the build machine.
Unlike Darwin OSes, where swiftCore runtime is guaranteed to be present
in /usr/lib, Linux doesn't have ABI stability and the stdlib of the
build machine is not at the specific location. So the built compiler
cannot relies on the shared object in the toolchain.
LLVM install_symlink takes a new argument on whether to create a symlink
or copy binaries when run. -- https://reviews.llvm.org/D145443
The variable that controls this in LLVM is `LLVM_USE_SYMLINKS`, which
defaults to `ON` on Unix-y hosts, but otherwise is false so that Windows
works. This is a configurable option, so Windows configs that can
support symlinks can take advantage of symlinks and save some space.
`LLVM_USE_SYMLINKS` is not exported from LLVM though, so we can't see
it to use. Instead, we have `SWIFT_USE_SYMLINKS`.
Rationale: we are using Swift compiler as a library in a downstream project and having these exposed would streamline version detection for our use case.
Additionally, this PR makes CMake config a bit more uniform with LLVM/Clang configs.
As of CMake 3.25, there are now global variables `LINUX=1`, `ANDROID=1`,
etc. These conflict with expressions that used these names as unquoted
strings in positions where CMake accepts 'variable|string', for example:
- `if(sdk STREQUAL LINUX)` would fail, because `LINUX` is now defined and
expands to 1, where it would previously coerce to a string.
- `if(${sdk} STREQUAL "LINUX")` would fail if `sdk=LINUX`, because the
left-hand side expands twice.
In this patch, I looked for a number of patterns to fix up, sometimes a
little defensively:
- Quoted right-hand side of `STREQUAL` where I was confident it was
intended to be a string literal.
- Removed manual variable expansion on left-hand side of `STREQUAL`,
`MATCHES` and `IN_LIST` where I was confident it was unintended.
Fixes#65028.
MSVC 17.6p3 introduced new ARM64 intrinsics for atomic
(load-acquire/store-release) operations. Since clang does not support
this yet, force the fallback path to temporarily unblock the build while
we implement support for the `__stlr[8|16|32|64]` intrinsics in clang.
See: llvm/llvm-project#62103
We need to pick up the `_swift_tsan_xxx` symbols from libswiftCore in
most cases, but sometimes we're statically linked and in that case we
want to use a local copy.
rdar://1106655213
`.swiftmodule` is listed as an output of pure swift libraries, but it
isn't updated if there's been no changes (just like the library and
its object files). Add it to the touch hack as well.
Swift *executables* also list `.swiftmodule` as an output, even though
one isn't generated at all. Add a new POST_BUILD command to touch it
regardless.
When building Swift code into the compiler (e.g, the new Swift parser
along with macros support), make sure we always add the appropriate
paths to (1) link against the host Swift toolchain, and (2) find the
host Swift libraries (such as SwiftSyntax) at runtime.
The CMake code for doing this was only running for Darwin builds, so
generalize it to also work on Linux.
Windows builds in waves:
- build build tools
- build tools (compilers, debuggers, linkers, assemblers)
- build runtimes (Swift runtime, standard library, experimental libraries)
- build core libraries
- build Swift tooling
We do not need to build the C++ interop module at the moment when
building the tools. This disables that and the extra content which
currently does not result in any artifacts.
Some versions of the swift driver have a bug where passing `-sanitize=`
does not emit the correct `-fsanitize=` flag for the clang link step.
Although this is being fixed, we must be able to correctly build with older
versions of the swift driver for some period of time. We workaround that
issue by explicitly passing the correct `-fsanitize=` argument
ourselves.
This works around rdar://107733898
Add a helper to allow us to programatically extract the Swift version
string during the build. This is particularly useful for injection into
the packaging stages.
Co-authored-by: Evan Wilde <etceterawilde@gmail.com>
swift_supports_implicit_module invokes /path/to/toolchain/usr/bin/swiftc
directly without using `xcrun`. That fails to set necessary
environmental variables to make swiftc infer the SDK path. Because of
that swift_supports_implicit_module used to fail because the test
compilation fails to load the stdlib. This PR workaround it by passing
`-parse-stdlib` to avoid implicit stdlib loading.
Our libraries have a `LC_LINKER_OPTION` for eg. `-lswiftLLVMJSON`.
This is resolved (probably just based on the actual libswiftLLVMJSON.a
added to the link command) by ld, but not by lld. Add in a link
directory so that these libraries can be found.
* Move `add_pure_swift_host_library()` from lib/CMakeLists.txt to
AddPureSwift.cmake so that code outside `lib` can use it
* Add `add_pure_swift_host_tool()` function to make a pure Swift
host executable target (for future usages)
* Specify depending `SwiftSyntax` modules explicitly because not all
Swift libraries uses all SwiftSyntax libraries
For future usage from other host libraries written in Swift
For CMake:
* Explicitly specify LINKER_LANGAGE to CXX in existing components so
that 'swiftc' is not used when linking with 'swiftASTGen'
* Add 'EMIT_MODULE' argument to 'add_pure_swift_host_library' to emit
.swiftmodule usable from other Swift libraries.
For unified builds, LLVM with the update to stable/20221013 includes its
own FindLibEdit, which shares many of the same names than Swift's
FindLibEdit, except that they differ in the target name.
Match both LLVM and Swift target names, so unified builds can find
LibEdit::LibEdit correctly and not try to link against libedit
mistakenly.
This should not affect Darwin/Linux builds from upstream Swift, since
they build non-unified in most people setups (including CI).
