mirrors/xtool
1
0
Fork 0
mirror of https://github.com/xtool-org/xtool.git synced 2026-11-14 03:24:55 +03:00
Code Issues Packages Projects Releases Wiki Activity
434 Commits 156 Branches 48 Tags
swb/cache-loc
Commit Graph

10 Commits

  • build: compile xtool with Swift 6.4 (#272) 
    ## What does this PR do?

Updates workflows to build with Swift 6.4. Blockers:

- [x] ~~GitHub's macos-26 runners don't yet support Xcode 27~~ They've
moved to a new nomenclature where the runner tracks the Xcode major
version. The new runner is `xcode-27`.
- [x] ~~Linux AppImage builds are failing due to
https://github.com/swiftlang/swift-build/issues/1764 (will be fixed in
6.4.1)~~ Switched to dynamic linking

## How was it tested?

- [x] Built locally with Xcode 27 and confirmed it runs
- [x] Built locally with `swift:6.4.0` docker image and confirmed it
runs

## 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 swiftlang/swift-package-manager#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

* **Build & Release**
  * macOS and iOS builds and macOS releases now use Xcode 27.
* Swift has been updated to version 6.4.0 for Docker and Netlify builds.

* **Bug Fixes**
* Linux packaging no longer copies `.resources` files into the AppDir,
which may affect packaged app resources.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->
    Kabir Oberai · 2026-10-04 16:53:13 -04:00
    1f28a80a13
  • build: link xtool dynamically inside AppImage (#296) 
    ## What does this PR do?

We don't really need `--static-swift-stdlib` when building the AppImage,
since we can bundle the stdlib.

Static linking _can_ theoretically save space & squeeze out a little
more perf, but statically linking Swift is buggy (for example
https://github.com/swiftlang/swift-build/issues/1764 wasn't caught until
days after 6.4.0 released, and months after the beta) and prevents using
dynamic Swift libraries.

## How was it tested?

- [x] Ran appimage in docker
- [x] Verified that the appimage contains `libswift[...].so`
- [x] Compared size on disk (<1MB increase)
- [x] Compared performance (no statistically significant change)

## 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-10-04 16:42:46 -04:00
    5807d01f03
  • Support xtool --version (#53)
    Kabir Oberai · 2025-05-21 18:16:46 +05:30
    fbbd8366ca
  • AppImage: fix zsync file name
    Kabir Oberai · 2025-05-16 01:03:02 +05:30
    65c120fd00
  • Add update info to AppImage (#42)
    Kabir Oberai · 2025-05-16 00:49:31 +05:30
    9ec9e6723c
  • Rename main product
    Kabir Oberai · 2025-05-06 11:30:59 +05:30
    6778e66e55
  • linuxdeploy tweaks
    Kabir Oberai · 2024-11-24 16:43:39 -08:00
    ddcdfaa972
  • cache linuxdeploy
    Kabir Oberai · 2024-11-24 16:10:06 -08:00
    63ba808d10
  • Usability improvements
    Kabir Oberai · 2024-11-24 14:16:08 -08:00
    64992c2317
  • Docker and Linux
    Kabir Oberai · 2024-11-17 03:47:16 -05:00
    6a59e7ad2e