Verify product dependencies w/ target platform, vs. hardcoded macOS

[peterkos]

Product dependencies are now verified using the buildEnvironment's platform, instead of the hardcoded macOS platform.

This builds on the work of #6732, now allowing cross-compilation of product dependencies 🎉

Motivation:

Let's say we're cross-compiling macOS -> iOS simulator, with a host system of macOS v13.

let package = Package(
    name: "SwiftFlashlight",
    products: [.library(...)],
    platforms: [.iOS(.v16)],
    dependencies: [
        // internally, for iOS(.v16), macOS(.v14)
        .package(url: "probably/alamofire", exact: "1.2.3")
    ],
    // ...
)

As long as we set our triple & SDK, we should be good... (and, with #6828, only the triple needed)

> swift build --triple arm64-apple-ios-simulator \
              --sdk "$(xcrun --sdk iphonesimulator --show-sdk-path)"
...
error: the library 'SwiftFlashlight' requires macos 10.13,
but depends on the product 'probably/alamofire' which requires macos 10.14;  [...]

Even though SwiftFlashlight only supports iOS(.v16), SupportedPlatform "[by] default, [...] assigns a predefined minimum deployment version for each supported platforms unless you configure supported platforms [...]". As a side-effect, macOS is inferred as a valid platform. (This is why no "target/platform mismatch" error was thrown.)

Previously, product dependencies were verified against macOS, rather than the target platform. Since macOS is always inferred, this surfaced as a "woah! your dependencies are out of sync".

let swiftFlashlight = Package(
    platforms: [
        .iOS(.v16),
        .macOS(.v13) // <-- inferred-|
    ],                               |
)                                    |-- // since --triple is .iOS,
                                     |   // shouldn't be comparing
let probably/alamofire = Package (   |   // macOS.
    platforms: [                     |
        iOS(.v16),                   |
        macOS(.v14)] // <-- inferred-|
    ]
)

Now, the intention of --triple is respected 🐱

Modifications:

• validateDeploymentVersionOfProductDependency accepts a buildEnvironment containing the target platform

Result:

Product dependencies can now be compiled for darwin other than macOS -- i.e, iOS :)

Future work

• Target-level or product-level platform support is still up in the air
• This only applies to triple.isDarwin() -- perhaps a next step of, verifying dependencies against non-darwin?

[peterkos]

This was a fun one to chase down 😅
(note to self: Apple Swift version 5.9 (swift-5.9-RELEASE))

Some questions:

• I tried running swiftformat but it changed 600+ files -- just BuildPlan was ~300 lines 😵, thoughts?
• Happy to add some tests around this; wanted to get some thoughts before diving in there :)

[MaxDesiatov]

I tried running swiftformat but it changed 600+ files -- just BuildPlan was ~300 lines 😵, thoughts?

Please run Utilities/soundness.sh script, which will only format files that were changed.

Happy to add some tests around this; wanted to get some thoughts before diving in there :)

Yes, please add the tests, that would be great. Thanks!

[peterkos]

Thanks! I'll take a crack at it soon :)

[peterkos]

@MaxDesiatov Apologies for the delay on this! One test added, one test modified 🧪

Since utilities/soundness.sh works from the git diff, I added a newline in each file I modified + ran the script as a separate commit for #reviewsanity. As you can see, those files haven't had a run in a while, heh.

[MaxDesiatov]

Thanks! Just as heads up, this will conflict with #7161

[peterkos]

Resolved conflicts 👍

Looks like soundness.sh disagrees with how Swift requires raw string literals to be formatted tho. One example:

// BuildPlanTests L#5749
func testArtifactsArchiveBinaryTargets(...) {
    // ...
                        "path": "all-platforms/mytool",
                        "supportedTriples": ["\(
                            artifactTriples.map(\.tripleString)
                                .joined(separator: "\", \"")
    )"]
                }
            ]
        }
    }
}
                    """
                //   ^ swiftformat throws this here,
                //     but is a swift build error :(

I've manually reverted the script's raw string changes for now, but it seems like the way swiftformat expands inline closures (among other things) could be improved -- that's my guess 🚀

Also the soundness.sh script didn't print any error output unless I tweaked L60. Assuming it's a me-issue, but can push up that change if useful.

swiftformat $changed_file > dev/null 2>&1 # old
swiftformat $changed_file 2>&1            # new

[MaxDesiatov]

@swift-ci test

[MaxDesiatov]

@swift-ci test windows

[MaxDesiatov]

@swift-ci test

[MaxDesiatov]

Thank you!

[MaxDesiatov]

@swift-ci test windows