xtool

cli: better IO (#375 )

## What does this PR do?

Adds `Dependency`s for console IO. Also fixes #268 by explicitly
handling non-pipe input.

## How was it tested?

Ran on macOS + Linux in Docker. I have a future PR that overrides the
dependencies in certain cases, which also appears to work correctly.

## 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

Did not scrutinize the tests too much tbh but they look reasonable. Easy
enough to update/remove them in the future if needed.

<!-- 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

* **New Features**
* Added support for reading command-line input, including asynchronous
prompts, line-based responses, and graceful handling of end-of-input.
  * Added coordinated cleanup when commands finish.
* **Improvements**
* Command messages across authentication, device management,
installation, SDK, and other workflows now use consistent output
handling; displayed messages and command behavior remain unchanged.
* Improved handling of complete output when the system temporarily
cannot accept more data.
* **Tests**
* Added coverage for command input and output, including stream
behavior, cancellation, and shutdown.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Kabir Oberai · 2026-10-28 17:48:38 -04:00

3e0c11d967

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 -->

Kabir Oberai · 2026-10-06 18:19:30 -04:00

8f0cc0adf1

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

## 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.

Kabir Oberai · 2026-09-20 02:47:12 -04:00

0108899e04

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 -->

Kabir Oberai · 2026-09-18 23:26:10 -04:00

6efd77fc0e

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. -->

Kabir Oberai · 2026-09-10 18:37:51 -04:00

4208c77c81

sdk: fix permission issue when copying clang resources (#255 )

## What does this PR do?

Fixes #254 by using `cp -R` instead of `FileManager.copyItem`. The
latter tries to preserve the original owner of files instead of using
the caller, which fails if you're non-root and the original files are
root-owned.

## How was it tested?

I was able to repro the original issue by installing an SDK as a
non-root user in an xtool Docker container.

Applied this patch, tried `xtool sdk install` again, and it worked.

## 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. -->

Kabir Oberai · 2026-09-10 17:23:15 -04:00

d4f6443f55

Use swift-subprocess (#225 )

Kabir Oberai · 2026-07-12 16:36:24 -04:00

5c4f3bcb05

Fix DarwinSDK legacy compat (#230 )

Kabir Oberai · 2026-05-28 01:50:58 -04:00

e49934c1fe

Fix clang headers (#228 )

A slightly different approach to #215.

---------

Co-authored-by: sfusco <slf@stevenfusco.com>

Kabir Oberai · 2026-05-28 01:43:22 -04:00

9c4772d64f

Validate SDK before overwriting (#192 )

Running an invalid `sdk` subcommand like `xtool sdk list` (there's no
`list` subcommand) is interpreted as "install the sdk at path `./list`".
We previously unconditionally removed the existing SDK during
installation. By switching the order so that we validate the path first,
we avoid performing a potentially destructive action unless we have
clear intent.

See #186.

Before:

```bash
$ xtool sdk list
Removing existing SDK... # destructive!
Error: Could not read file or directory at path 'list'.
```

After:

```bash
$ xtool sdk list
Error: Could not read file or directory at path 'list'.
  See 'xtool help sdk' for usage.
```

Kabir Oberai · 2026-01-04 21:55:35 -05:00

7a5dfd2ccd

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.

Kabir Oberai · 2025-08-10 01:43:09 -04:00

836fca8daf

Add SwiftLint (#104 )

Closes #72

Kabir Oberai · 2025-05-31 19:38:57 +05:30

0425f9edeb

Improve SDK handling (#40 )

* Use swift-sdk commands instead of file ops

* comment

Kabir Oberai · 2025-05-16 00:06:39 +05:30

54d03f525a

Create sdks directory if needed

Kabir Oberai · 2025-05-08 23:41:34 +05:30

307df68794

More renaming and regrouping

Kabir Oberai · 2025-05-06 12:31:48 +05:30

7245b34f4f

15 Commits