Skip to content

[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

Merged

Conversation

gottesmm
Copy link
Contributor

This PR consists of two small cmake changes that prepare the way for the stage 2 bootstrap swift build.

  1. The first ensures that we search the passed in toolchain's path before looking in the SDK. This is important since when we perform a stage2 build, we pass in the stage1's installed artifacts as the SDK. At that point we have not split the just built toolchain libraries from the set of just built SDK libraries. This causes us to link against the just built compatibility libraries if they are built causing weird build errors.
  2. The second one changes the stdlib build's swiftc variable to respect SWIFT_BUILD_RUNTIME_WITH_HOST_COMPILER. Today, we always set it to ${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.

gottesmm added 2 commits June 27, 2021 16:40
…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.
@gottesmm gottesmm requested a review from drexin June 27, 2021 23:48
@gottesmm
Copy link
Contributor Author

@swift-ci test

@finagolfin
Copy link
Member

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.

@swift-ci
Copy link
Contributor

Build failed
Swift Test Linux Platform
Git Sha - c0d6d8f

@drexin
Copy link
Contributor

drexin commented Jun 28, 2021

@swift-ci test linux

@drexin
Copy link
Contributor

drexin commented Jun 28, 2021

@swift-ci test windows

Copy link
Contributor

@drexin drexin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@gottesmm
Copy link
Contributor Author

@buttaface I haven't hit anything.

@gottesmm gottesmm merged commit ceb54d3 into swiftlang:main Jun 28, 2021
@gottesmm gottesmm deleted the pr-ffc2f8bbbc47f85ce1988bfefd5b32d61085ca4e branch June 28, 2021 17:34
@davezarzycki
Copy link
Contributor

Hi @gottesmm -- This broke my "unified build" setup. The problem seems to be that I have SWIFT_BUILD_RUNTIME_WITH_HOST_COMPILER set to true but CMAKE_Swift_COMPILER is not set, which later breaks the setting of swift_compiler_tool. We've talked about these changes in the past. Should I let my scripts find the installed copy of Swift now? If so, then it seems like we ought to tune CMake to detect this bad configuration, no?

@gottesmm
Copy link
Contributor Author

@davezarzycki were all of your issues fixed by that PR?

@davezarzycki
Copy link
Contributor

davezarzycki commented Jun 30, 2021

Yes, although now I probably won't use SWIFT_BUILD_RUNTIME_WITH_HOST_COMPILER as often now because sometimes I do want the stdlib to be built with the just-built swift. Thanks for checking.

EDIT -- And SWIFT_BUILD_RUNTIME_WITH_HOST_COMPILER now complicates bisecting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants