Commit Graph

30 Commits

  • xcode: track paths on XcodeProject (#388)
    ## What does this PR do?
    
    An XcodeProject/XcodeWorkspace now knows its own location on disk, which
    is important when we start using these types to build PIF.
    
    ## How was it tested?
    
    - [x] Used in future PRs to build various Xcode projects
    
    ## 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
    -->
    <!-- coderabbit-ai-generated:v1 -->
    
    ## Summary by CodeRabbit
    
    * **Improvements**
    * Projects and workspaces now retain their associated locations and save
    directly to those locations.
    * Generated project files preserve the configured project directory
    path, helping keep file references consistent when projects are written
    or reopened.
    * Projects and workspaces can be associated with a new location while
    retaining their existing contents.
    <!-- end of auto-generated comment: release notes by coderabbit.ai -->
  • pack: link edited dependencies into the builder package (#390)
    ## What does this PR do?
    
    SwiftPM looks for edited dependencies in the root package's Packages
    directory. The builder package becomes the root when building, so
    dependencies edited with `swift package edit` were ignored and SwiftPM
    fetched them again instead.
    
    <!-- Focus on *what* the PR does in essence. The *how* should come
    second, if it's relevant. -->
    
    ## How was it tested?
    
    Without this change, the build of `xtool/.xtool-tmp` tries to clone all
    15 dependencies and fails.
    
    * With `Packages` linked into `.xtool-tmp`, it builds without fetching
    anything and produces `DemoTCA.app`
    * `Examples/DemoSimple`, which has no `Packages` directory, still builds
    * `swift test` passes
    
    <!-- e.g. Ran locally on macOS and added unit tests -->
    
    ## 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
    -->
    
    <!-- coderabbit-ai-generated:v1 -->
    
    ## Summary by CodeRabbit
    
    * **Build Improvements**
    * Builds now include access to the working directory’s `Packages` folder
    when it exists. If the folder is absent, builds proceed without it. This
    can make packages in that folder available during the build.
    
    <!-- end of auto-generated comment: release notes by coderabbit.ai -->
    
    Signed-off-by: Anish Pallati <i@anish.land>
  • packer: custom SwiftVersion parser (#303)
    ## What does this PR do?
    
    Drops `mxcl/Version` in favour of a lighter parser that's specifically
    designed to parse the Swift version.
    
    ## How was it tested?
    
    - [x] Unit tests
    - [x] CI
    
    ## 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**
    * Swift versions can now be compared by major, minor, and patch number,
    and displayed in a consistent three-part format.
    * Version parsing now accepts two- or three-number versions, including
    supported compiler-output formats with optional prefixes or a `-dev`
    suffix.
    * Versions with an omitted patch number are treated as equivalent to the
    same version with patch `0`.
    
    <!-- end of auto-generated comment: release notes by coderabbit.ai -->
  • 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 -->
  • planner: skip macro targets (#208)
    Currently, when using a package with macros like TCA the build fails
    with the following message.
    ```
    Error: Could not find package containing product 'SwiftSyntaxMacros'
    ```
    
    <!-- This is an auto-generated comment: release notes by coderabbit.ai
    -->
    
    ## Summary by CodeRabbit
    
    * **Bug Fixes**
    * Package planning now skips macro targets when collecting resources and
    resolving dependencies. This prevents dependencies belonging to macro
    targets from being traversed as part of planning, while leaving
    dependency handling for other target types unchanged.
    
    <!-- end of auto-generated comment: release notes by coderabbit.ai -->
    
    Co-authored-by: Kabir Oberai <oberai.kabir@gmail.com>
  • tests: derive CFBundleSupportedPlatforms from the build triple (#289)
    ## What does this PR do?
    
    Application packing now sets CFBundleSupportedPlatforms from
    Packer.cfBundleSupportedPlatforms(for:). The helper splits the triple on
    hyphens, takes the OS token after apple with any numeric version
    stripped, and returns iPhoneSimulator for an ios triple that also
    contains simulator, iPhoneOS for other ios triples, MacOSX for macos or
    macosx, and iPhoneOS when the triple is missing or unrecognized.
    PackerTests covers those triples. Package.resolved drops the
    swift-issue-reporting pin and adds xctest-dynamic-overlay 1.13.1.
    
    Application builds aimed at the iOS simulator still ship an Info.plist
    whose CFBundleSupportedPlatforms value is iPhoneOS. Hosts that read that
    key treat the archive as a physical-device build and refuse to launch it
    on a simulator. While packing an application, Packer assigns
    CFBundleSupportedPlatforms the fixed array iPhoneOS. The build triple is
    already available on buildSettings, but that assignment never reads it,
    so a simulator triple is packed the same way as a device triple.
    
    Fixes #191
    
    ## How was it tested?
    
    The package builds successfully.
    
    ## AI tool usage
    
    How much of this PR was AI-assisted? (check one)
    
    - [ ] **0** - No AI was used to write code
    - [ ] **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
    
    AI was used for assistance.
    
    
    <!-- This is an auto-generated comment: release notes by coderabbit.ai
    -->
    
    ## Summary by CodeRabbit
    
    * **Bug Fixes**
    * Application metadata now reports the supported platform based on the
    build target, including iOS devices, iOS simulators, and macOS. Unknown
    targets retain the iOS device platform as a fallback.
    * **Tests**
    * Added coverage for platform metadata across supported and unknown
    build targets.
    
    <!-- end of auto-generated comment: release notes by coderabbit.ai -->
    
    Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>
  • package: bump deps (#281)
    ## What does this PR do?
    
    Bumps pointfree deps and explicitly disables OpenCombine so that we
    don't have different dependency graphs when building xtool on Darwin vs
    Linux hosts.
    
    ## How was it tested?
    
    A bunch of `swift package resolve`s
    
    ## AI tool usage
    
    How much of this PR was AI-assisted? (check one)
    
    - [x] **0** - No AI was used to write code
    - [ ] **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
    
    * **Chores**
    * Updated supporting package versions and refreshed command-line and
    file-operation handling.
    * These changes do not add or remove app features or alter its public
    interface. No action is needed to continue using the app.
    <!-- end of auto-generated comment: release notes by coderabbit.ai -->
  • sdk: get clang resources from swift toolchain (#274)
    ## What does this PR do?
    
    When building the SDK, derives the clang resource dir from the installed
    Swift toolchain (`swiftc -print-target-info`) instead of `clang
    -print-resource-dir`.
    
    Speculatively fixes #273.
    
    ## How was it tested?
    
    Validated that I can still build on Linux
    
    ## 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
    
    * **Bug Fixes**
    * Improved detection of the host Clang resource directory by using Swift
    compiler target information, helping ensure more reliable compiler setup
    across supported environments.
    
    <!-- end of auto-generated comment: release notes by coderabbit.ai -->
  • sdk: update darwin-tools and OAM (#270)
    ## What does this PR do?
    
    Bumps darwin-tools and OpenAppleMacros
    
    - Updates LLD to support arm64e.x1 to fix #269
    - Adds FoundationModelsMacros to fix #213
    
    ## How was it tested?
    
    - [x] Confirm that we can build with an Xcode 27 release SDK on Linux
    - [x] Confirm that FoundationModels APIs work
    
    ## AI tool usage
    
    How much of this PR was AI-assisted? (check one)
    
    - [x] **0** - No AI was used to write code
    - [ ] **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
    
    * **Bug Fixes**
    * Improved Darwin SDK tool discovery during Swift builds, including
    support for locating `dsymutil`.
    
    * **Updates**
      * Updated bundled Darwin tool dependencies.
    * Added Foundation Models macros support to the OpenAppleMacros library
    set.
    
    <!-- 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 -->
  • sdk: move DarwinSDK into PackLib (#256)
    ## What does this PR do?
    
    Mechanical move of DarwinSDK from XToolSupport -> PackLib. Needed for
    https://github.com/xtool-org/xtool/pull/229.
    
    ## How was it tested?
    
    Compiled + CI
    
    ## AI tool usage
    
    How much of this PR was AI-assisted? (check one)
    
    - [x] **0** - No AI was used to write code
    - [ ] **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. -->
  • Handle static xcframeworks not being unpacked (#156)
    SwiftPM may not unpack static xcframeworks. Handle this gracefully, if
    SwiftPM doesn't need the framework we don't either.
    
    Fixes #155.
  • 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>
  • 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.
  • Pacify type checker
    Swift 6.1’s type checker couldn’t resolve the original expr in reasonable time yada yada