Skip to content

Conversation

@etcwilde
Copy link
Member

@etcwilde etcwilde commented Jul 1, 2025

Install swiftmodules using the full module triple. This replaces the CMake logic that attempts to compute the appropriate architecture using values passed into CMake with a query to ask the compiler what the appropriate module triple is for the given input target triple. This is more robust mechanism and will future-proof this part of the code against any new platforms and architectures to anything that the Swift compiler building the project can support.

This is currently needed for the x86_64 FreeBSD bringup effort, where the amd64 architecture should be spelled x86_64 in the swiftmodule triple for the Swift compiler to find it. A surgical approach adding another condition for amd64 FreeBSD would have less risk, but would also require a new tag for every new platform that the get_swift_host_arch didn't compute correctly or hadn't considered. The approach in the commit will work for all new platforms. Bugs in this approach will come from issues in the compiler when targeting the new platform and can be fixed in the compiler without changes to Swift-Collections.

Install swiftmodules using the full module triple. This replaces the
CMake logic that attempts to compute the appropriate architecture using
values passed into CMake with a query to ask the compiler what the
appropriate module triple is for the given input target triple.
This is more robust mechanism and will future-proof this part of the
code against any new platforms and architectures to anything that the
Swift compiler building the project can support.

This is currently needed for the x86_64 FreeBSD bringup effort, where
the `amd64` architecture should be spelled `x86_64` in the swiftmodule
triple for the Swift compiler to find it. A surgical approach adding
another condition for amd64 FreeBSD would have less risk, but would also
require a new tag for every new platform that the `get_swift_host_arch`
didn't compute correctly or hadn't considered. The approach in the
commit will work for all new platforms. Bugs in this approach will come
from issues in the compiler when targeting the new platform and can be
fixed in the compiler without changes to Swift-Collections.
@etcwilde etcwilde self-assigned this Jul 1, 2025
@etcwilde etcwilde requested a review from lorentey as a code owner July 1, 2025 17:10
@etcwilde etcwilde moved this to In Progress in Swift on FreeBSD Jul 1, 2025
@etcwilde
Copy link
Member Author

etcwilde commented Jul 1, 2025

CC @compnerd

Copy link
Member

@lorentey lorentey left a comment

Choose a reason for hiding this comment

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

Very nice, thank you! 👍

@lorentey lorentey added this to the 1.1.5 milestone Jul 1, 2025
@lorentey
Copy link
Member

lorentey commented Jul 2, 2025

@swift-ci test

@etcwilde
Copy link
Member Author

etcwilde commented Jul 2, 2025

@swift-ci please test macOS

1 similar comment
@justice-adams-apple
Copy link

@swift-ci please test macOS

@etcwilde etcwilde merged commit ad9f672 into apple:release/1.1 Jul 2, 2025
2 checks passed
@github-project-automation github-project-automation bot moved this from In Progress to Done in Swift on FreeBSD Jul 2, 2025
@etcwilde etcwilde deleted the ewilde/1.1-nested-swift-modules branch July 2, 2025 17:29
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.

3 participants