-
Notifications
You must be signed in to change notification settings - Fork 1.4k
[bootstrap] Add a --skip-cmake-bootstrap flag to use a prebuilt swift-build #3000
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
Conversation
0beb536
to
1578327
Compare
@swift-ci please smoke test |
This seems reasonable but this should definitely be controlled by an option (and bootstrapping from source should likely be the default, with an option to skip it an use a prebuilt swift-build instead). @aciidb0mb3r Do you have any concerns with this or know some of the background? One thing that concerns me is that the SwiftPM in the toolchain might be too old to build the current SwiftPM's main-branch sources, and that would result in some fairly subtle errors. |
@compnerd How would this interact with the Windows support? The more I think about this, the more it seems to me that this would be a great option to add to the bootstrap script, but that it shouldn't be on by default (for the reason I mentioned earlier). That should still enable the Android support that's mentioned, since those build scripts can presumably pass the flag. |
Will do.
I only pass in a toolchain that was built from the same unmodified commit, but obviously this feature will depend on the developer passing in a reasonable toolchain. |
Great! Yes, my concern was just with people who might not realize that have an old toolchain and then try to figure out why they get errors while bootstrapping the mainline code. So if you're fine with making it an option without changing the default, that would be great. I think that there are already some options like that in the |
This definitely will break the Windows CI - do we really need the bootstrap option for CMake? At least, can we make it enabled by default? The bootstrap script isn't used on Windows as it had issues due to rsync usage and path handling. Removing the |
be856c4
to
6dd031a
Compare
Updated so this is only enabled by a flag and made the CMake variable more descriptive and better documented. |
…-build Rather than building with CMake and then using that freshly built swift-build to build it with itself, add this flag to check for a prebuilt swift-build next to swiftc and use that instead if it's there. The PackageDescription libraries are still built using CMake, as this repo's Package.swift only builds the latest 4_2 version.
6dd031a
to
c815b71
Compare
Ping, ready to merge? |
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.
Thanks @buttaface. This looks good to me.
@@ -198,6 +202,8 @@ def parse_build_args(args): | |||
args.bootstrap_dir = os.path.join(args.target_dir, "bootstrap") | |||
args.conf = 'release' if args.release else 'debug' | |||
args.bin_dir = os.path.join(args.target_dir, args.conf) | |||
args.bootstrap = not args.skip_cmake_bootstrap or \ | |||
not os.path.exists(os.path.join(os.path.split(args.swiftc_path)[0], "swift-build")) |
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.
As a refinement, would it make sense to emit an error if --skip-cmake-bootstrap
is true but there's no swift-build
, rather than going through with the bootstrap?
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.
I figured it's better to then try the bootstrap build as a backup, but could go either way. If you prefer, I can add a warning or error out in my next pull to cross-compile SPM for Android.
@swift-ci please smoke test |
Thanks, now I need to clean up my patches cross-compiling SPM for Android and submit that pull. |
Rather than building with CMake and then using that freshly built swift-build to build it with itself, add this flag to check for a prebuilt swift-build next to swiftc and use that instead if it's there. The PackageDescription libraries are still built using CMake, as this repo's Package.swift only builds the latest 4_2 version.
This is part of my patches to cross-compile the corelibs and SPM for Android using the official prebuilt Swift toolchain for Ubuntu, as it doesn't make sense to rebuild a native SPM before cross-compiling it, since the official toolchain already has a native swift-build.
I tested this pull with the Oct. 22 source snapshot and official prebuilt snapshot toolchain after applying this small patch to build-script in the main Swift repo:
The first two were not strictly necessary, but allowed me to skip building LLVM and corelibs targets that aren't needed. I then added the prebuilt Swift to my path and built, tested, and installed SPM without bootstrapping without a problem, similar to how I did the same with the corelibs in swiftlang/swift#32922:
I
t might make sense toadded a flag todisenable this,and forcedefaulting to a bootstrap build even if a prebuilt swift-build is found, say if you made some changes to the SPM source that require bootstrapping with a modified SPM. I will submit a pull next so that a prebuilt Swift toolchain can be passed to the build-script and the single needed build-script patch above won't be.Since some of this pull just avoids dependencies in the CMake build that are no longer needed when only building the PackageDescription libraries with CMake, it might be better to get the other PD library built with Package.swift and the prebuilt SPM instead, but I don't know if that's possible or why it isn't already done.