Sanity check - build/packaging instructions with bundle Metal libraries #345
Description
This is not specifically a mlx-swift issue. It is a bundling and package issue focusing on the presence (or lack thereof) of the default.metallib dependency in tools that use mlx-swift. I imagine I am not the only person who needs or wants to build signed and notarized package installers for applications with bundled Metal dependencies so hopefully this work can help shed some light on the process.
It is also not a "bug" report. I appear to have a working solution but because my knowledge of both Metal and Apple's packaging tools is shallow I am hoping someone can check what I've got and point out any obvious problems or mistakes.
The context is a simple package which exports a handful of libraries and a command-line tool for doing targeted LLM-based operations using the MLX packages or, if present, the built-in FoundationModels:
https://github.com/sfomuseum/Docent/blob/main/Package.swift
We need to build a signed and notarized binary (for the command-line tool) that uses mlx-swift with bundled Metal dependencies which can be installed using a plain-vanilla .pkg file. The build part is handled here, following the instructions to use xcodebuild rather than swift build:
https://github.com/sfomuseum/Docent?tab=readme-ov-file#building
That works as expected meaning I can move the final binary tool out of the build folder, delete the build folder entirely and run the binary tool (invoking the mlx-swift code as expected.
After a bit of trial and error I was finally able to accomplish the same for a signed and packaged version of that binary by copying the mlx-swift_Cmlx.bundle, generated during the build process, in to the package root used by the pkgbuild tool:
https://github.com/sfomuseum/Docent?tab=readme-ov-file#packaging-and-signing
All of which seems to work so that's good. But is it correct? Or, more importantly, is it obviously incorrect ?
Thanks,