Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Rewrite #15

Open
brentleyjones opened this issue Apr 3, 2023 · 0 comments
Open

Feature Request: Rewrite #15

brentleyjones opened this issue Apr 3, 2023 · 0 comments
Assignees

Comments

@brentleyjones
Copy link
Contributor

brentleyjones commented Apr 3, 2023

I’ve learned a lot about Xcode, Bazel, and integrating together since I started this project. In particular, with the development of rules_xcodeproj, I’ve come to realize that this project as it currently exists isn’t sufficient to create a maintainable general purpose XCBBuildService proxy solution.

To that end, I’ve decided to rewrite the project. Below are some of the keys changes in the rewrite. The main reason for a rewrite versus incremental changes, are because of major difference in how XCBProtocol is handled.

  • XCBProtocol is version-less
    • Models have all properties that any supported version of Xcode uses
    • Xcode version is passed to encoder/decode and used to determine how to serialize/deserialize
    • Supports MessagePack or JSON serialization (some message payloads have changed format over time)
    • Enums cases are properly mapped based on version (removing a case adjusts the integer value of subsequent vases)
  • MessagePack serialization is a Codable implementation
  • Swift concurrency is used instead of SwiftNIO
    • Xcode sessions are actors
    • Builds are actors
  • Logging (swift-log) is replaced with Logger (OSLog)
  • XCBBuildService and RequestHandler are replaced by a XCBBuildServiceProxyKit.Proxy protocol, which functions similar to SwiftUI.App
  • Tools/tests to detect XCBProtocol changes in new Xcode versions
  • Extensive developer documentation, including a DocC website for API and a “usage” document

To support code reviews while the rewrite is happening, development will happen on a dedicated branch, which main will fast forward to once it reaches an approximate feature parity state. This issue will serve as an Epic, and we might create smaller issues for specific pieces mentioned above (if needed beyond simply creating a PR).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

No branches or pull requests

1 participant