Skip to content

Reinstate "Use Swift 5.7 base image for Swift CI jobs to support bootstrapping" #341

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

Closed

Conversation

DougGregor
Copy link
Member

With swiftlang/swift#66199, we're close(r) to the point where we can build the Swift compiler that integrates Swift code built using the host Swift.

@DougGregor
Copy link
Member Author

@swift-ci please test

@@ -1,8 +1,8 @@
FROM amazonlinux:2
FROM swift:5.7-amazonlinux2
Copy link
Contributor

Choose a reason for hiding this comment

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

should this be pinned to 5.7 or use the latest release?

Copy link
Contributor

Choose a reason for hiding this comment

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

Pinned makes sense to me given that we support releases up to 12 months back. So 5.7/5.8/.5.9. Though ideally we'd have a build for 5.8 + 5.9 going as well.


ENV PATH="${PATH}:/opt/swift/usr/bin"

RUN swift --version
Copy link
Contributor

Choose a reason for hiding this comment

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

this is a surprising change. why do we need to do this? should we fix the docker image instead if this is fixing something?

Copy link
Contributor

Choose a reason for hiding this comment

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

Ideally all our release images would install into /opt/swift/<version> instead of /usr. But we don't want to break current clients, so for now we're just updating the builder image.

Without this change, Swift uses the toolchain-clang to build and then uses the system C++ stdlib instead of devtoolset as it should. The system stdlib is wildly out of date (unsurprising) and thus doesn't have any new C++ features.

@shahmishal given all the other images are using the toolchain clang, perhaps we should make this ENV PATH=/opt/swift/usr/bin:${PATH} instead of appending?

Copy link
Member

Choose a reason for hiding this comment

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

@shahmishal given all the other images are using the toolchain clang, perhaps we should make this ENV PATH=/opt/swift/usr/bin:${PATH} instead of appending?

Yes, that make sense.

Copy link
Member

Choose a reason for hiding this comment

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

this is a surprising change. why do we need to do this? should we fix the docker image instead if this is fixing something?

We can change this in 5.9 release, if the community is ok with the change. I would like to avoid this type of change in dot release.

@tomerd
Copy link
Contributor

tomerd commented Jun 15, 2023

Ideally all our release images would install into /opt/swift/ instead of /usr

this is where I was going with my questions. I think we should fix this going forward

@tomerd
Copy link
Contributor

tomerd commented Jun 15, 2023

cc @etcwilde @MaxDesiatov

@etcwilde
Copy link
Member

Yep, using /opt/swift-<version> means we can install toolchains for multiple versions of swift (important since we don’t have ABI stability guarantees on Linux), and so that we don’t conflict with the distribution toolchains. This is consistent with how redhat and centos bundle additional and newer toolchains. It’s also consistent the UNIX directory hierarchy spec.

reserved for the installation of add-on application software packages.

It gives us a lot more flexibility for how we want to distribute things.

@tomerd
Copy link
Contributor

tomerd commented Jun 15, 2023

fwiw, not all distributions like things in /opt so this may need to be refined per distribution, but 100% with the approach and we should def fix it in the toolchain packaging itself since its more correct

@bnbarham
Copy link
Contributor

bnbarham commented Jul 6, 2023

I've updated to use a downloaded toolchain rather than the base image for all Linux platforms - #346. Made a new PR since I wanted to rebase + squash.

@shahmishal shahmishal closed this Nov 4, 2023
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