Skip to content

Latest commit

 

History

History
39 lines (24 loc) · 4.4 KB

xcode-workspace.md

File metadata and controls

39 lines (24 loc) · 4.4 KB

Generated Xcode Workspace

RepoPrompt CE provides a generated, disposable Xcode workspace for development convenience. Package.swift and Package.resolved remain the canonical target graph and dependency lock; conductor, SwiftPM, and Scripts/package_app.sh remain the authoritative build, test, and app-packaging paths.

Generate and open

Xcode 26 and Python 3 are required.

make xcode            # generate and open
make xcode-generate   # generate without opening
make xcode-check      # verify existing output is current
make xcode-validate   # regenerate, check structure, and run xcodebuild -list
make xcode-clean      # remove generated workspace metadata

The generator writes .build/xcode/RepoPromptCE.xcworkspace. Everything under .build/xcode is derived and ignored; never edit or commit it. Regenerate after changes to the package manifest, lockfile, generator, or Xcode workflow wrapper. make xcode generates the workspace before opening it; use make xcode-validate when explicit package-acquisition and xcodebuild -list validation is required.

Schemes in Xcode 26.3

Xcode exposes SwiftPM product schemes, including RepoPrompt and repoprompt-mcp, alongside three repository convenience schemes:

The native RepoPrompt product scheme retains the shipped product, target, and emitted-binary identity. Internally, that executable is now a one-file entry target over the RepoPromptApp implementation library. RepoPromptApp is an internal SwiftPM target rather than a declared library product, so it does not add a supported product or convenience scheme. The AppKit-free RepoPromptDomainRuntime and direct RepoPromptDomainRuntimeTests owner target are likewise internal package targets discovered from the same manifest; they do not add product or convenience schemes.

  • RepoPrompt CE App delegates to conductor to assemble the real debug app through the existing packaging flow, verifies the .build/debug/RepoPrompt.app compatibility path, then runs the local debug bundle under ~/Library/Application Support/RepoPrompt CE/DebugApps/RepoPrompt.app.
  • RepoPrompt CE MCP delegates to conductor to build and run .build/debug/repoprompt-mcp.
  • RepoPrompt CE Tests delegates to the conductor test runner, which owns the sandboxed test environment the root suites require. Test targets depend on library targets only (RepoPromptMCPCore replaced the former RepoPromptMCP executable dependency); the scheme remains a build target rather than a native Xcode test bundle.

The native product schemes are useful for source navigation and indexing. Use RepoPrompt CE Tests for the supported full test workflow; optional REPOPROMPT_XCODE_TEST_FILTER narrows the delegated run. External dependency test targets are not added to RepoPrompt schemes. Sparkle's vendored XCFramework declares a dSYMs directory that is not present in the repository, so native Xcode package builds involving the app can fail before compilation. The generator deliberately does not mutate Vendor/; the packaged app convenience scheme remains the supported app build.

Boundaries

This workflow is Debug-only. It does not define a second source graph, alter Package.swift, replace SwiftPM test resources, or support release/archive packaging. The app scheme permits ad-hoc signing when no stable identity is available; set REPOPROMPT_XCODE_SIGN_IDENTITY to choose an Apple Development identity explicitly. Ad-hoc builds use ephemeral secure storage.

Generated app, MCP, and test builds are conductor-coordinated. Xcode cancellation can stop waiting without canceling the queued daemon job; inspect ./conductor job list before retrying. The explicit REPOPROMPT_XCODE_UNCOORDINATED=1 fallback is build/test-only. Xcode Run still requires conductor so its pre-launch action can perform exact-executable lifecycle handling safely.

Validation ownership

Generated-workspace validation, including deterministic generation and the xcodebuild -list check, is owned by make xcode-validate. Run it locally when needed, let pr-ready select it for executable Xcode workspace boundary changes, or use the dedicated Xcode Workspace Validation workflow for manual, scheduled, PR path-filtered, and main path-filtered hosted coverage. Existing SwiftPM/conductor build and test jobs remain authoritative for product behavior. The hosted workflow also tracks this documentation page; docs-only changes do not broaden the local pr-ready lane.