Skip to content

Support binary XCFramework dependencies in SPM build system#75

Merged
obj-p merged 2 commits intomainfrom
fix/xcframework-deps
Apr 10, 2026
Merged

Support binary XCFramework dependencies in SPM build system#75
obj-p merged 2 commits intomainfrom
fix/xcframework-deps

Conversation

@obj-p
Copy link
Copy Markdown
Owner

@obj-p obj-p commented Apr 10, 2026

Summary

  • SPM copies pre-built .framework bundles (from binaryTarget / XCFramework deps like lottie-spm) directly into binPath rather than producing .build/ directories with loose .o files
  • The Tier 2 bridge compilation was missing these entirely — no -F search path, no -framework flags, and no -rpath for dlopen
  • Add collectFrameworks() to scan binPath for .framework bundles and emit the correct compiler/linker flags

Closes #69 (partial — the original fix handled source-compiled deps but missed binary targets)

What changed

  • SPMBuildSystem.swift: New collectFrameworks(binPath:) method scans for .framework bundles. Flags added: -F <binPath>, -framework <Name>, -Xlinker -rpath -Xlinker <binPath>
  • examples/spm: Added lottie-spm (binary XCFramework) as a dependency with import Lottie and LottieView usage in the preview
  • PreviewSessionBuildContextTests: Added assertions for -F, -framework, and -rpath flags

Test plan

  • swift test --filter PreviewSessionBuildContext — all 5 tests pass (includes Tier 2 compile with Lottie XCFramework)
  • swift run previewsmcp snapshot examples/spm/Sources/ToDo/ToDoView.swift — renders correctly with Lottie binary dep
  • Existing sibling target and path dependency linking still works (-lToDoExtras, -lLocalDep)

🤖 Generated with Claude Code

obj-p and others added 2 commits April 10, 2026 17:25
SPM copies pre-built .framework bundles (from binaryTarget/XCFramework
deps like lottie-spm) directly into binPath rather than producing
.build/ directories with loose .o files. The Tier 2 bridge compilation
was missing these entirely — no -F search path, no -framework flags,
and no -rpath for dlopen.

Add collectFrameworks() to scan binPath for .framework bundles and
emit -F, -framework, and -rpath flags so both compilation and runtime
loading succeed.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Remove unused `import Lottie` from Item.swift (ToDoView.swift already
  exercises the framework dependency)
- Verify the actual framework name ("Lottie") follows the -framework
  flag, not just that the flag exists

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@obj-p obj-p enabled auto-merge (squash) April 10, 2026 21:39
@obj-p obj-p merged commit 4ea8cbd into main Apr 10, 2026
4 checks passed
@obj-p obj-p deleted the fix/xcframework-deps branch April 10, 2026 21:58
obj-p added a commit that referenced this pull request Apr 10, 2026
…vention

The example's Package.resolved has never been committed across the repo's
history (checked via git log --all -- examples/spm/Package.resolved) —
not since the original SPM example in #3, nor through #75 which just added
a new remote dependency on lottie-spm. Meanwhile the root /Package.resolved
IS tracked, and CI hashes only the root one (.github/workflows/ci.yml).

The rationale is that examples/spm is a testbed for PreviewsMCP's SPM
build system. Leaving its Package.resolved unpinned means every fresh
checkout / CI run exercises a fresh dependency resolution, so upstream
breakage in deps like lottie-spm surfaces promptly instead of being
masked by pinned versions.

Previously this convention was implicit — the file was just left
untracked, polluting every `git status`. Make it explicit with a scoped
gitignore entry (the specific path, not a blanket `Package.resolved`
that would also affect the tracked root file) and a comment documenting
the rationale.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
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.

SPM build doesn't include package dependencies in build context

1 participant