-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[SR-237][build-script] Migrate more of build-script-impl to Python #1267
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
Care for a code review, @practicalswift? 😉 Also, I've run |
# `tar` from emitting a warning). | ||
if args.install_symroot: | ||
os.chdir(args.install_symroot) | ||
swift_build_support.tar.tar(source=prefix.lstrip('/'), |
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 feel like the tar() function itself should be doing chdir() -- and back. We have a WorkingDirectory
class in utils/SwiftBuildSupport.py, by the way.
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.
Can do!
Just want to say, thanks for doing this. You’re scratching a long-standing itch! |
@dabrahams Yes of course! Glad to do it. I'm think the build scripts could be much simpler, but it will take some time to remove |
(Just FYI, I won't be at a computer for a few days. I'll update this around Sunday night or on Monday.) |
@swift-ci Please test |
@swift-ci Please test OS X platform |
@modocache Reviewed - LGTM 👍 :-) Thanks for cleaning this up! |
@modocache Regarding the One warning remains in the code base (although currently ignored) if you want to take a look at it: |
Rather than determining whether to build Ninja in the build-script-impl shellscript, do so in the Python build-script. A small step towards achieving SR-237.
Rather than determining which builds to skip in the build-script-impl shellscript, do so in the Python build-script. A small step towards achieving SR-237.
Rather than printing `xcodebuild` version information in the build-script-impl shellscript, do so in the Python build-script. A small step towards achieving SR-237.
Rather than setting a default value for the INSTALL_PREFIX in the build-script-impl shellscript, do so in the Python build-script. A small step towards achieving SR-237.
Rather than setting the path to the .xctoolchain in the build-script-impl shellscript, do so in the Python build-script. A small step towards achieving SR-237.
@gribozavr I've hopefully addressed your comments! 👍
Please have another look and let me know if there are any other issues I can address. |
@modocache Thank you! If we would use Does the |
Oh! Sorry, I hadn't realized #801 was still open, I had misremembered that a pull request to use gzip had been merged. It looks like LZMA2 compression was introduced in Python 3.3, so I guess @gribozavr In #1267 (comment) you mention having |
@gribozavr Updated! Let me know if you have any additional comments. Also, could you provide me with a sample invocation of the "buildbot_osx_package" preset? It's the only preset in |
Rather than archiving symbols at the very end of the build-script-impl shellscript, do so at the end of the Python build-script. A small step towards achieving SR-237.
@swift-ci Please test |
@modocache Thank you! You can see an invocation example at the top of the CI page: https://ci.swift.org/view/Packages/job/oss-swift-package-osx/ Here's an example with all variables: export TOOLCHAIN_VERSION=swift-DEVELOPMENT-SNAPSHOT-2016-02-15-a
export ARCHIVE="${TOOLCHAIN_VERSION}-osx.tar.gz"
export SYM_ARCHIVE="${TOOLCHAIN_VERSION}-osx-symbols.tar.gz"
export BUNDLE_IDENTIFIER="org.swift.30${YEAR}${MONTH}${DAY}a"
export DISPLAY_NAME="Xcode Swift DEVELOPMENT Snapshot ${YEAR}-${MONTH}-${DAY} (a)"
export TOOLCHAIN_NAME="${TOOLCHAIN_VERSION}"
export SWIFT_SOURCE_ROOT="${WORKSPACE}"
export SWIFT_BUILD_ROOT="${WORKSPACE}/build"
export SWIFT_INSTALLABLE_PACKAGE="${WORKSPACE}/${ARCHIVE}"
export SWIFT_INSTALL_DIR="${WORKSPACE}/swift-nightly-install"
export SWIFT_INSTALL_SYMROOT="${WORKSPACE}/swift-nightly-symroot"
export SWIFT_TOOLCHAIN_DIR="/Applications/Xcode.app/Contents/Developer/Toolchains/${TOOLCHAIN_NAME}.xctoolchain"
export SYMBOLS_PACKAGE="${WORKSPACE}/${SYM_ARCHIVE}"
export DARWIN_TOOLCHAIN_VERSION="3.0.${YEAR}${MONTH}${DAY}01"
"${WORKSPACE}/swift/utils/build-script" --preset="buildbot_osx_package" \
install_destdir="${SWIFT_INSTALL_DIR}" \
installable_package="${SWIFT_INSTALLABLE_PACKAGE}" \
install_toolchain_dir="${SWIFT_TOOLCHAIN_DIR}" \
install_symroot="${SWIFT_INSTALL_SYMROOT}" \
symbols_package="${SYMBOLS_PACKAGE}" \
darwin_toolchain_bundle_identifier="${BUNDLE_IDENTIFIER}" \
darwin_toolchain_display_name="${DISPLAY_NAME}" \
darwin_toolchain_xctoolchain_name="${TOOLCHAIN_NAME}" \
darwin_toolchain_version="${DARWIN_TOOLCHAIN_VERSION}" \
darwin_toolchain_alias="swift" |
[SR-237][build-script] Migrate more of build-script-impl to Python
Thanks, @gribozavr! Also thank you for pointing me to the invocations on the CI page, these will be very useful as I continue to work on SR-237. |
What's in this pull request?
Six commits that each move a little more code out of the
utils/build-script-impl
shellscript, into Python. This is pursuant to the goals in SR-237.These commits do not introduce any breaking changes--using the
migrate_impl_args
function introduced in #761, arguments meant for build-script-impl are routed to build-script instead.Why merge this pull request?
It makes progress on SR-237. The goal is to eventually eliminate an entire step from the Swift build process, to simply have Python invoke CMake (instead of an additional shellscript being executed in between).
What are the downsides to merging this pull request?
This pull request contains multiple changes that could be broken up into individual pull requests. I opted against separate pull requests because I thought maintainers would find it noisy. Also, the sixth commit in this stack depends on commits four and five, and GitHub doesn't have a great way of specifying dependencies in pull requests.