-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[5.9][CMake] Support Macros in Linux #68190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[5.9][CMake] Support Macros in Linux #68190
Conversation
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.
This enables running macro tests on Linux.
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. (cherry picked from commit 9c9010e)
Many shared libs and executables are only run after stdlib/runtime are built. They don't need to link with builders stdlib at all. (cherry picked from commit 2a2787b)
and Swift parser integration is enabled. If swift parser integration is enabled, SwiftSyntax libraries are always built with host tools. Other SwiftCompilerSources modules must use the same runtime with parser libraries. (cherry picked from commit 0f0c492)
(cherry picked from commit 9017ef5)
SourceKit components are never built while bootstrapping stages. So it doen't need to have stage 0 or 1 handling. (cherry picked from commit 914a6fd)
`$ORIGIN` is only supported in Linux, BSD, etc. (i.e. not in Windows) (cherry picked from commit 602604b)
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. (cherry picked from commit 757aaa3)
recursive-lipo requires shared libraries have +x permissions. Use PROGRAMS instead of FILES when installing swift-syntax libraries. (cherry picked from commit 319b8bd)
libSwiftScan is built in 'lib' but installed in 'lib/swift/host' RUNPATH should have correct '$ORIGIN/../{platform}' to load 'swiftCore' runtime library. (cherry picked from commit 4ccc866)
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. (cherry picked from commit dc68773)
RPATH_SET is not available until cmake 3.21.0. Use RPATH_CHANGE instead. (cherry picked from commit f645069)
swiftlang/llvm-project#7345 |
@@ -107,6 +107,16 @@ function(get_bootstrapping_swift_lib_dir bs_lib_dir bootstrapping) | |||
elseif("${bootstrapping}" STREQUAL "") | |||
get_bootstrapping_path(bs_lib_dir ${lib_dir} "1") | |||
endif() | |||
elseif(BOOTSTRAPPING_MODE STREQUAL "HOSTTOOLS") | |||
if(SWIFT_HOST_VARIANT_SDK MATCHES "LINUX|ANDROID|OPENBSD|FREEBSD") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a bunch of places we're only checking for Linux and others where we check for DARWIN and then else. Given we haven't checked the other platforms, should we just check for LINUX for now?
@@ -367,3 +367,12 @@ StaticInitCloner::clone(SingleValueInstruction *initVal) { | |||
} | |||
return cast<SingleValueInstruction>(getMappedValue(initVal)); | |||
} | |||
|
|||
// START: Workaround for C++ interop |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you pick a random file or is this the one I randomly picked? Would probably be better to put this in its own file, but given it's only needed for 5.9 ... 🤔
Some non-stdlib thing e.g. swift-backtrace still might be built before the runtime is built. For building Swift code in Linux "hosttools", always set 'LD_LIBRARY_PATH' to the runtime in the builder. (cherry picked from commit 0aa0aac)
RPATH to 'lib/swift/host' was missing in Darwin platform. (cherry picked from commit 9d78971)
"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' (cherry picked from commit 8049922)
When Swift parser integration is disabled (i.e. NOT SWIFT_SWIFT_PARSER), macro plugins targets are not created. So CMake should bail out. (cherry picked from commit ad2dacd)
Ubuntu 18.04 seems to be defaulting to 'ascii', causing an error when using line-directive combined with the utf-8 diagnostic output used when early swift syntax is enabled. (cherry picked from commit afd3f17)
829c3b7
to
7c5bc7c
Compare
swiftlang/llvm-project#7345 |
7c5bc7c
to
9e7c16f
Compare
swiftlang/llvm-project#7345 |
9e7c16f
to
71f5b47
Compare
swiftlang/llvm-project#7345 |
Cherry-pick #66199 and #68082 into
release/5.9
swiftCore
in/usr/lib
or any other stable location, executables and shared libraries that contains Swift module need to haveRUNPATH
to the runtime in its own toolchain. This PR forces "hosttools" bootstrapping mode, but set theRUNPATH
to the currently-being-built toolchain.