Disuse unversioned triples on non-Darwin platforms.

[3405691582]

Disuse unversioned triples on non-Darwin platforms.

Motivation:

The target flag should take the versioned triple, otherwise on platforms
with versioned triples, the standard library won't be found.

On Darwin, the unversioned triple should still be used throughout. This
necessitates special-casing in the bootstrap script and when making
subdirectories during the build.

See TSC pr #229.

Modifications:

• Utilities/bootstrap: get the versioned triple from swiftc, not the unversionedTriple.
• Sources/Basics/Triple+Extensions.swift and Sources/Basics/CMakeLists.txt: introduce a new extension to and method on Triple from TSC to get the correct .build subdirectory for Darwin and non-Darwin platforms, platformBuildPathComponent
• Sources/Commands/SwiftTool.swift: ensure platformBuildPathComponent is used.
• Amended filter in BinaryTarget+Extensions.swift to deal with comparing tripleStrings instead of triple structs, so we can properly do the unversioning on Darwin.
• Relevant tests updated to match.

Result:

When bootstrapping swiftpm, the target will be filled with the versioned triple on non-Darwin systems.

This must be applied in concert with the TSC pr.

[finagolfin]

Btw, once TSC can handle versioned triples with your pull, swiftlang/swift-tools-support-core#229, does SPM properly pass those along to the Swift compiler, particularly when cross-compiling, or is further patching needed in SPM?

I need to modify TSC to handle Android versions too, which are appended to the environment, not the OS.

[3405691582]

I can only really speak affirmatively to the platforms I have access to, but the -target flag appears to be appropriately set by SPM post the TSC change on OpenBSD and Linux. I don't believe further SPM patching should be required for the versioned triple changes but as you said Android may need to do something special.

[finagolfin]

I think this should work, but why not switch macOS to versioned triples too instead?

@aciidb0mb3r, any reason not to do that now that TSC would support it with his TSC pull?

[neonichu]

@swift-ci please smoke test

[3405691582]

Tests have been updated and some code cleaned up a little to factor this recurring pattern.

[neonichu]

@swift-ci please smoke test

[neonichu]

@swift-ci please smoke test

[3405691582]

The extension is moved to Basics now to make sure that it is accessible everywhere, including in all relevant tests. All uses of tripleString in the tests were converted to using the new platformBuildPathComponent method where appropriate.

[abertelrud]

@swift-ci please smoke test

[abertelrud]

@swift-ci please smoke test

[3405691582]

As edited, amended filter BinaryTarget+Extensions.swift to ensure triples are compared by tripleString and not triple themselves, so we can do the unversioning of triples on Darwin, to ensure the plugin tests that check for supportedTriples passes.

[abertelrud]

@neonichu What is the next step here?

[finagolfin]

Btw, I was just looking at the much more extensive Triple struct in SwiftDriver, which already supports API versioning for Android though perhaps not OpenBSD, as it was a port of the LLVM triple. Should we switch over to that instead, rather than using this more limited TSCUtility triple, which predates that Swift port?

[3405691582]

Migrating the Triple module from the Driver is probably a bigger lift for another PR, I suspect, but the others on the pr may still want to comment on whether that works on a more tactical basis.

[neonichu]

I think in principle that should work, but IIRC we did not want to depend on the driver outside of the targets that already depend on it to avoid the data model library product taking on that dependency. It looks like Workspace depends on SPMBuildCore which needs the triple, so that would violate that constraint.

@abertelrud might have more context.

[finagolfin]

Does this need to be run through the CI too or can the three pulls be merged together now?

[neonichu]

swiftlang/swift-tools-support-core#229
swiftlang/sourcekit-lsp#430
@swift-ci please smoke test

[finagolfin]

Ping, these three pulls appear ready, two just need to be approved before all are merged together.

[neonichu]

Yep, I am planning to take a final look this week and approve.

[neonichu]

All three PRs look good to me, we should wait for Ben to approve swiftlang/sourcekit-lsp#430 and then we can land this.