Add the MLX backend product to the SwiftPM package template

[shoumikhin]

Supersedes #22204. Same change, plus the fix for a defect that made the new resource bundle empty for every real consumer.

What #22204 got wrong

The metallib resource list was gated on FileManager.default.fileExists with a path relative to the process working directory:

letmlxResourcesDir=".Package.swift/backend_mlx_resources"resources: mlxMetallibSlices.compactMap { slice inFileManager.default.fileExists(atPath:"\(mlxResourcesDir)/\(slice).metallib")?.copy("\(slice).metallib"):nil}

SwiftPM evaluates a dependency's manifest with the consumer's directory as the working directory, not the dependency's checkout. So every slice looked absent, compactMap returned [], and SwiftPM emitted no bundle at all. The build stayed green with no warning, and the MLX delegate would fault later at Metal device init inside a consumer's app with nothing pointing at the cause.

Measured from a real consumer package, with all three metallibs committed and present in the resolved checkout:

before: Build complete! bundles: 0 metallibs shipped: 0
after: Build complete! bundles: 1 metallibs shipped: 3
.build/out/Products/Debug/executorch_backend_mlx_resources.bundle

That bundle name is what backends/mlx/CMakeLists.txt compiles in as SWIFTPM_BUNDLE, so it is the name the delegate actually looks for.

Why it was easy to miss

Every in-place check passes. swift package dump-package run inside the package root reports all three resources, and --package-path chdirs to the package root too, so it is equally blind. Only resolving the package as a dependency exposes it. The release job's own guards check for unsubstituted checksums and for products without frameworks, neither of which can see this.

The fix

Declare the three slices unconditionally instead of probing for them. The release job commits all three files to this branch before publishing, so the probe was guarding against a state that does not occur on a published branch. import Foundation is no longer needed, and the base template did not have it.

What a genuinely missing slice does now, measured rather than assumed:

swift package resolve -> says nothing at all
swift build -> warning: 'dep': Invalid Resource 'mlx-ios.metallib': File not found
Build complete! (a warning, not an error)

So this makes the failure visible, not fatal. That is still a large improvement over the old form, which shipped zero of three metallibs with no diagnostic of any kind, but it is worth being precise: SwiftPM does not fail a build on a missing declared resource.

Landing

This half and the main-side half (#22203) both need to be live before the next Apple publish run. Order between them does not matter: each single-sided state trips one of the release job's two guards and exits 1 before git push -f, so nothing broken is published either way. Verified by replaying the substitution and both guards for all three states.

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/22259

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 Unclassified Failure

As of commit 0e56f2b with merge base 1d467d0 ():

UNCLASSIFIED FAILURE - DrCI could not classify the following job because the workflow did not run on the merge base. The failure may be pre-existing on trunk or introduced by this PR:

• PR #22259 / Analyze (actions) (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  CodeQL could not process any code written in GitHub Actions. For more information, review our troubleshooting guide at https://gh.io/troubleshooting-code-scanning/no-source-code-seen-during-build .

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[shoumikhin]

Superseded by a branch carrying two further review fixes: the comment no longer implies the main-side manifest is wrong for using FileManager.fileExists (it anchors with #filePath and is correct), and the single-use path local is inlined to match the sibling style. Reopening rather than leaving those unaddressed, since this repository blocks direct pushes to a branch once it has an open PR.