-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[cmake] Prepare for stage2 bootstrap swift build #38123
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
[cmake] Prepare for stage2 bootstrap swift build #38123
Conversation
…iling host swift code. This ensures that we pick up libraries from the toolchain before picking up libraries from the SDK we are using. Normally it would not matter the order that we add these -L files since the contents of the SDK and toolchain are disjoint. Once we begin performing stage2 swift builds though, we no longer have this property since we pass in the stage1's installed libraries as the SDK directory and we have not split the two sets of libraries yet. The end result is that if we have the -L in the previous order, we will pick up just built compatibility libraries before we pick up the actual compatibility libraries from the actual toolchain we are using to compile. This results in compilation breakage.
… the stdlib if SWIFT_NATIVE_SWIFT_TOOLS_PATH is not set and CMake_Swift_COMPILER is. Previously, no matter if SWIFT_BUILD_RUNTIME_WITH_HOST_COMPILER was set, we would use for swiftc SWIFT_NATIVE_SWIFT_TOOLS_PATH/bin/swiftc. This is correct assuming that the user always passed in that flag. This will no longer always be true since we are attempting to transition the stdlib slowly to use more standard cmake. Instead, in that case if SWIFT_BUILD_RUNTIME_WITH_HOST_COMPILER is set and SWIFT_NATIVE_SWIFT_TOOLS_PATH is not set /and/ we have a CMAKE_Swift_COMPILER, we just use CMAKE_Swift_COMPILER. Hopefully with time we get rid of SWIFT_NATIVE_SWIFT_TOOLS_PATH.
@swift-ci test |
Btw, do you hit SR-14796 if you try to build the standalone stdlib like this with an official prebuilt trunk or 5.5 snapshot build for linux? That may affect people trying to use this pull with a prebuilt snapshot toolchain. |
Build failed |
@swift-ci test linux |
@swift-ci test windows |
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.
LGTM
@buttaface I haven't hit anything. |
Hi @gottesmm -- This broke my "unified build" setup. The problem seems to be that I have |
@davezarzycki were all of your issues fixed by that PR? |
Yes, although now I probably won't use EDIT -- And |
This PR consists of two small cmake changes that prepare the way for the stage 2 bootstrap swift build.
${SWIFT_NATIVE_SWIFT_TOOLS_PATH}/swift
. This is implemented by checking if SWIFT_NATIVE_SWIFT_TOOLS_PATH is not set and if so setting the variable to the just built swift directory so that the stdlib uses the just built swift binary directory. This /does/ work when SWIFT_BUILD_RUNTIME_WITH_HOST_COMPILER is set to true but just incidentally since in the past we have always assumed that SWIFT_BUILD_RUNTIME_WITH_HOST_COMPILER meant that SWIFT_NATIVE_SWIFT_TOOLS_PATH is actually set by the user. Instead, in this commit I am changing the cmake to set swiftc based off of CMAKE_Swift_COMPILER if SWIFT_NATIVE_SWIFT_TOOLS_PATH was not initially set. Hopefully we eventually eliminate these external swift tools path in favor of more idiomatic CMake constructs.