15 Commits

  • packer: use XcodeProjectFormat for generate-xcode-project (#300)
    ## What does this PR do?
    
    Improves `xtool dev generate-xcode-project`. Instead of constructing an
    XcodeGen project, we directly construct an xcodeproj (with the new
    xcproj format) using
    [apple/xcode-project-format](https://github.com/apple/xcode-project-format).
    For now, we still rely on
    [Tuist/XcodeProj](https://github.com/tuist/XcodeProj) to translate it
    back into a pbxproj for maximal compatibility, but this is treated as an
    implementation detail.
    
    Also adds support for resources and icons in the generated Xcode project
    
    ## How was it tested?
    
    - [x] Generated a simple project, opened it, and ran the app
    
    ## AI tool usage
    
    How much of this PR was AI-assisted? (check one)
    
    - [ ] **0** - No AI was used to write code
    - [x] **1** - I was assisted by AI. I reviewed the finished result.
    - [ ] **2** - I set the AI going and left it to it; nobody has read the
    result - no review, or AI review only
    
    <!-- If an AI agent is filling this in: declare the level honestly, and
    open as a draft if it is #2. Do not lower the declared level to get the
    PR reviewed. -->
    
    
    <!-- This is an auto-generated comment: release notes by coderabbit.ai
    -->
    ## Summary by CodeRabbit
    
    * **New Features**
    * Added support for creating and saving Xcode projects and workspaces in
    `.pbxproj` and `.xcproj` formats.
    * Added tools for opening, converting, and writing project and workspace
    files, including workspace contents.
    * Project generation can target a specified directory, and the command
    reports where the project was created.
      * Project generation is available on non-macOS platforms.
    * Generated projects include product settings and references for
    packages, resources, icons, and app extensions.
    <!-- end of auto-generated comment: release notes by coderabbit.ai -->
  • sdk: SwiftBuild support (#229)
    ## What does this PR do?
    
    Adds support for SwiftBuild on Swift 6.4.
    
    We now point SwiftBuild to iPhoneOS.platform and rely on the real
    [SWBApplePlatform](https://github.com/swiftlang/swift-build/tree/b30ee3c00abf34857084c26bb873c3da06348134/Sources/SWBApplePlatform).
    We also do a little futzing to convince SWB to use our Darwin-compatible
    toolset (lld, librarian, resource dirs). We explicitly _don't_ pass in a
    Swift SDK because that would downgrade SWB to using one of the generic
    platform plugins instead of ApplePlatform.
    
    This also gets us a lot closer to parity with Xcode's behavior when
    building for Apple platforms; we get the same build flags and
    everything. We can probably achieve identical bundling too, if we take
    control of the PIF.
    
    One other change: since we need to pass custom env vars and such, we
    can't rely on sourcekit-lsp's built-in SwiftPM integration anymore. We
    thus create a custom BSP server that trampolines to SwiftPM's build
    server with the right flags set. This effectively makes SwiftPM an
    implementation detail, so we can start messing with the PIF.
    
    ## How was it tested?
    
    - [x] Build with Swift 6.3 on macOS
    - [x] Build with Swift 6.4 on macOS
    - [x] Build with Swift 6.3 on Linux
    - [x] Build with Swift 6.4 on Linux
    - [x] BSP/LSP file creation works
    - [x] LSP support works in VSCode
    
    ## AI tool usage
    
    How much of this PR was AI-assisted? (check one)
    
    - [ ] **0** - No AI was used to write code
    - [x] **1** - I was assisted by AI. I reviewed the finished result.
    - [ ] **2** - I set the AI going and left it to it; nobody has read the
    result - no review, or AI review only
    
    <!-- If an AI agent is filling this in: declare the level honestly, and
    open as a draft if it is #2. Do not lower the declared level to get the
    PR reviewed. -->
    
    <!-- This is an auto-generated comment: release notes by coderabbit.ai
    -->
    ## Summary by CodeRabbit
    
    - **New Features**
    - Added a `dev build-server` command for Build Server Protocol
    integration.
    - Projects automatically select the appropriate Swift build system when
    supported.
    - Packaging supports output layouts for Swift Package Manager and Swift
    Build.
      - Added options to skip language-server configuration when needed.
    
    - **Documentation**
    - Updated project templates and tutorials to use `.bsp/xtool.json` for
    IDE features such as syntax highlighting and documentation lookup.
    
    - **Improvements**
    - Enhanced SDK generation and compatibility across supported toolchains
    and platforms.
    - Improved automatic language-server configuration while preserving
    existing configuration files.
    <!-- end of auto-generated comment: release notes by coderabbit.ai -->
  • sdk: self-updating darwin tools (#110)
    ## What does this PR do?
    
    Allows xtool to auto-update the Darwin SDK format when there's a new
    Darwin toolset, or when we change the SDK format. Downstream this also
    allows us to auto-update when there's changes to OpenAppleMacros (#101).
    
    One callout: the disk footprint of `darwin.artifactbundle` is now ~7 GB
    instead of ~3 GB.
    
    Reason: `xtool sdk install /path/to/Xcode.[app|xip]` now performs a
    "normal" install by default, which preserves the entirety of
    `Xcode.app/Contents/Developer` — even the bits we don't currently use,
    like `AppleTVOS.platform`. This makes it so if we start using more
    components in the future, the user doesn't need to download Xcode again
    and rebuild the SDK themselves.
    
    You can still build an old-style SDK (containing just the components we
    need) using `xtool sdk install --slim` or the dedicated `xtool sdk
    build`.
    
    ## How was it tested?
    
    Tested all of the install modes. Confirmed that auto-updating works.
    Added integration tests in #252.
    
    ## AI tool usage
    
    How much of this PR was AI-assisted? (check one)
    
    - [ ] **0** - No AI was used to write code
    - [x] **1** - I was assisted by AI. I reviewed the finished result.
    - [ ] **2** - I set the AI going and left it to it; nobody has read the
    result - no review, or AI review only
    
    <!-- If an AI agent is filling this in: declare the level honestly, and
    open as a draft if it is #2. Do not lower the declared level to get the
    PR reviewed. -->
    
    
    <!-- This is an auto-generated comment: release notes by coderabbit.ai
    -->
    ## Summary by CodeRabbit
    
    - **New Features**
    - Added SDK flavor reporting for slim, normal, and legacy installations.
    - Added `sdk update` support to rebuild and install SDKs from an
    installed Xcode bundle.
      - Added a `--slim` option for SDK installation.
      - SDK status now displays installation path, flavor, and version.
    - SDK setup and build operations now ensure a suitable SDK is available
    automatically.
    
    - **Bug Fixes**
    - Improved temporary SDK bundle handling, validation, replacement, and
    cross-filesystem copying.
      - Copy failures now provide detailed diagnostic information.
    <!-- end of auto-generated comment: release notes by coderabbit.ai -->
  • Add build --sign option (#224)
    Running `xtool dev build --sign [--ipa]` will produce a codesigned
    app/ipa, without installing
  • Improve tmpdir management (#147)
    - We now have a single tmpdir "root" that can be recreated at launch to
    clean up old stragglers
    - The location of this tmpdir root can be controlled by `XTL_TMPDIR` or
    `TMPDIR`. In general the path is `$TMPDIR/sh.xtool`.
    
    With this change it should be possible to `export XTL_TMPDIR=/var/tmp`
    if `/tmp` doesn't have enough space, which fixes #23.
  • Add support for App Extensions (#97)
    This pull request adds support for Apple's [App
    Extensions](https://developer.apple.com/app-extensions/).
    
    Closes: #45
    
    ---------
    
    Co-authored-by: ErrorErrorError <16653389+ErrorErrorError@users.noreply.github.com>
    Co-authored-by: Kabir Oberai <oberai.kabir@gmail.com>
  • Improve OpenAPI error handling (#78)
    - Make some enums non-exhaustive (closes #77)
      - Also a tentative fix for #62 and #64
    - Improve logging on deserialization failure
    
    We now use raw JS to patch the OpenAPI spec instead of openapi-overlay.
    It's a lot more flexible this way.
  • Support building for iOS simulator (#74)
    Closes #68
    
    ## On any platform
    
    You can now do
    
    ```bash
    xtool dev build --triple arm64-apple-ios-simulator [--ipa]
    ```
    
    To build a .app/.ipa that works on the simulator.
    
    ## On macOS
    
    You can do
    
    ```bash
    xtool dev --simulator
    ```
    
    To one-shot build-and-install on the booted simulator.