starred/komorebi
1
0
Fork 0
mirror of https://github.com/LGUG2Z/komorebi.git synced 2026-01-11 14:40:25 +01:00
Code Issues 87 Packages Projects Releases 10 Wiki Activity

[FEAT]: Support aarch64 builds on GitHub Actions #495

New Issue
Closed
opened 2026-01-05 14:51:06 +01:00 by adam · 5 comments
adam commented 2026-01-05 14:51:06 +01:00
Owner
Copy Link

Originally created by @LGUG2Z on GitHub (Oct 15, 2024).

Sponsorship Information

GitHub Sponsors

Suggestion

In the last week there have been two aarch64 machine users who have joined the community and with the growing popularity of both the software and ARM Windows laptops, it probably won't be long until there are more.

We need to have aarch64 builds happening as part of our regular builds against every commit and PR, and also have aarch64 builds available in the tagged releases.

Things that need to be researched:

  • How does scoop handle packages which target multiple architectures?
  • How does winget handle packages which target multiple architectures?
  • Are changes needed to upstream scoop and winget manifests?
  • Does GitHub Actions support aarch64 Windows runners?
  • Do we need to use something like cross-rs?

This is probably also a good time to completely overhaul our GitHub actions workflows since they are a huge mess and I hate touching them.

Alternatives Considered

  • aarch64 users compile from source? Gross
Originally created by @LGUG2Z on GitHub (Oct 15, 2024). ### Sponsorship Information GitHub Sponsors ### Suggestion In the last week there have been two `aarch64` machine users who have joined the community and with the growing popularity of both the software and ARM Windows laptops, it probably won't be long until there are more. We need to have `aarch64` builds happening as part of our regular builds against every commit and PR, and also have `aarch64` builds available in the tagged releases. Things that need to be researched: * How does `scoop` handle packages which target multiple architectures? * How does `winget` handle packages which target multiple architectures? * Are changes needed to upstream `scoop` and `winget` manifests? * Does GitHub Actions support `aarch64` Windows runners? * Do we need to use something like [`cross-rs`](https://github.com/cross-rs/cross)? This is probably also a good time to completely overhaul our GitHub actions workflows since they are a huge mess and I hate touching them. ### Alternatives Considered * `aarch64` users compile from source? Gross
adam added the github_actions label 2026-01-05 14:51:06 +01:00
adam closed this issue 2026-01-05 14:51:06 +01:00
adam commented 2026-01-05 14:51:06 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Oct 15, 2024):

I tried running cross build --target aarch64-pc-windows-msvc locally and got this error:

The following warnings were emitted during compilation:

warning: libz-sys@1.1.20: Compiler family detection failed due to error: ToolNotFound: Failed to find tool. Is `cl.exe` installed? (see https://docs.rs/cc/latest/cc/#compile-time-requirements for help)

error: failed to run custom build command for `libz-sys v1.1.20`

Caused by:
  process didn't exit successfully: `C:\Users\LGUG2Z\komorebi\target\debug\build\libz-sys-460dba889d8e73a0\build-script-build` (exit code: 1)
  --- stdout
  cargo:rerun-if-env-changed=LIBZ_SYS_STATIC
  cargo:rerun-if-changed=build.rs
  cargo:rerun-if-changed=zng/cmake.rs
  cargo:rerun-if-changed=zng/cc.rs
  note, vcpkg did not find zlib: Could not find Vcpkg tree: No vcpkg installation found. Set the VCPKG_ROOT environment variable or run 'vcpkg integrate install'
  TARGET = Some(aarch64-pc-windows-msvc)
  OPT_LEVEL = Some(0)
  cargo:rerun-if-env-changed=VCINSTALLDIR
  VCINSTALLDIR = None
  cargo:rerun-if-env-changed=VSTEL_MSBuildProjectFullPath
  VSTEL_MSBuildProjectFullPath = None
  HOST = Some(x86_64-pc-windows-msvc)
  cargo:rerun-if-env-changed=CC_aarch64-pc-windows-msvc
  CC_aarch64-pc-windows-msvc = None
  cargo:rerun-if-env-changed=CC_aarch64_pc_windows_msvc
  CC_aarch64_pc_windows_msvc = None
  cargo:rerun-if-env-changed=TARGET_CC
  TARGET_CC = None
  cargo:rerun-if-env-changed=CC
  CC = None
  cargo:rerun-if-env-changed=CC_ENABLE_DEBUG_OUTPUT
  cargo:warning=Compiler family detection failed due to error: ToolNotFound: Failed to find tool. Is `cl.exe` installed? (see https://docs.rs/cc/latest/cc/#compile-time-requirements for help)
  RUSTC_WRAPPER = None
  cargo:rerun-if-env-changed=CRATE_CC_NO_DEFAULTS
  CRATE_CC_NO_DEFAULTS = None
  CARGO_CFG_TARGET_FEATURE = Some(neon)
  DEBUG = Some(true)
  cargo:rerun-if-env-changed=CFLAGS_aarch64-pc-windows-msvc
  CFLAGS_aarch64-pc-windows-msvc = None
  cargo:rerun-if-env-changed=CFLAGS_aarch64_pc_windows_msvc
  CFLAGS_aarch64_pc_windows_msvc = None
  cargo:rerun-if-env-changed=TARGET_CFLAGS
  TARGET_CFLAGS = None
  cargo:rerun-if-env-changed=CFLAGS
  CFLAGS = None

  --- stderr


  error occurred: Failed to find tool. Is `cl.exe` installed? (see https://docs.rs/cc/latest/cc/#compile-time-requirements for help)

I installed all the C++ development tools from the Visual Studio installer but I still don't have cl.exe 🤔

@LGUG2Z commented on GitHub (Oct 15, 2024): I tried running `cross build --target aarch64-pc-windows-msvc` locally and got this error: ``` The following warnings were emitted during compilation: warning: libz-sys@1.1.20: Compiler family detection failed due to error: ToolNotFound: Failed to find tool. Is `cl.exe` installed? (see https://docs.rs/cc/latest/cc/#compile-time-requirements for help) error: failed to run custom build command for `libz-sys v1.1.20` Caused by: process didn't exit successfully: `C:\Users\LGUG2Z\komorebi\target\debug\build\libz-sys-460dba889d8e73a0\build-script-build` (exit code: 1) --- stdout cargo:rerun-if-env-changed=LIBZ_SYS_STATIC cargo:rerun-if-changed=build.rs cargo:rerun-if-changed=zng/cmake.rs cargo:rerun-if-changed=zng/cc.rs note, vcpkg did not find zlib: Could not find Vcpkg tree: No vcpkg installation found. Set the VCPKG_ROOT environment variable or run 'vcpkg integrate install' TARGET = Some(aarch64-pc-windows-msvc) OPT_LEVEL = Some(0) cargo:rerun-if-env-changed=VCINSTALLDIR VCINSTALLDIR = None cargo:rerun-if-env-changed=VSTEL_MSBuildProjectFullPath VSTEL_MSBuildProjectFullPath = None HOST = Some(x86_64-pc-windows-msvc) cargo:rerun-if-env-changed=CC_aarch64-pc-windows-msvc CC_aarch64-pc-windows-msvc = None cargo:rerun-if-env-changed=CC_aarch64_pc_windows_msvc CC_aarch64_pc_windows_msvc = None cargo:rerun-if-env-changed=TARGET_CC TARGET_CC = None cargo:rerun-if-env-changed=CC CC = None cargo:rerun-if-env-changed=CC_ENABLE_DEBUG_OUTPUT cargo:warning=Compiler family detection failed due to error: ToolNotFound: Failed to find tool. Is `cl.exe` installed? (see https://docs.rs/cc/latest/cc/#compile-time-requirements for help) RUSTC_WRAPPER = None cargo:rerun-if-env-changed=CRATE_CC_NO_DEFAULTS CRATE_CC_NO_DEFAULTS = None CARGO_CFG_TARGET_FEATURE = Some(neon) DEBUG = Some(true) cargo:rerun-if-env-changed=CFLAGS_aarch64-pc-windows-msvc CFLAGS_aarch64-pc-windows-msvc = None cargo:rerun-if-env-changed=CFLAGS_aarch64_pc_windows_msvc CFLAGS_aarch64_pc_windows_msvc = None cargo:rerun-if-env-changed=TARGET_CFLAGS TARGET_CFLAGS = None cargo:rerun-if-env-changed=CFLAGS CFLAGS = None --- stderr error occurred: Failed to find tool. Is `cl.exe` installed? (see https://docs.rs/cc/latest/cc/#compile-time-requirements for help) ``` I installed all the C++ development tools from the Visual Studio installer but I still don't have `cl.exe` 🤔
adam commented 2026-01-05 14:51:06 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Oct 15, 2024):

https://www.qovery.com/blog/how-to-make-rust-multi-arch-release-easy/

Could possibly be useful, though I would like to remove our dependency on goreleaser completely 🤔

@LGUG2Z commented on GitHub (Oct 15, 2024): https://www.qovery.com/blog/how-to-make-rust-multi-arch-release-easy/ Could possibly be useful, though I would like to remove our dependency on `goreleaser` completely 🤔
adam commented 2026-01-05 14:51:06 +01:00
Author
Owner
Copy Link

@bbedward commented on GitHub (Oct 15, 2024):

You likely need to host an arm64 windows GitHub runner. Not sure if cross compiling is possible given this projects dependencies.

there are some hosted services such as WarpBuild, but not sure if they have windows arm64 runners (seems like not)

@bbedward commented on GitHub (Oct 15, 2024): You likely need to host an arm64 windows GitHub runner. Not sure if cross compiling is possible given this projects dependencies. there are some hosted services such as WarpBuild, but not sure if they have windows arm64 runners (seems like not)
adam commented 2026-01-05 14:51:07 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Oct 16, 2024):

Not sure if cross compiling is possible given this projects dependencies

Luckily I found this action which did a lot of the heavy lifting with regards to cross-compilation: https://github.com/houseabsolute/actions-rust-cross - I don't know what it does but it works!

@LGUG2Z commented on GitHub (Oct 16, 2024): > Not sure if cross compiling is possible given this projects dependencies Luckily I found this action which did a lot of the heavy lifting with regards to cross-compilation: https://github.com/houseabsolute/actions-rust-cross - I don't know what it does but it works!
adam commented 2026-01-05 14:51:07 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Oct 16, 2024):

I iterated on a bunch of changes I had to enable this in the whkd repo: a04b9d5fc1/.github/workflows/windows.yaml (L23)

I managed to cut a release with both x86_64 and aarch64 binaries through the workflow and I've migrated largely the same approach here: 92dd3169ca

I have set up a release dry run job which will run on every master commit to hopefully get ahead of any breaking workflow changes quickly in the future.

From the whkd update experience it seems like the WinGet updater action will not pick up the new arch target so it will need to be updated manually when the action creates the PR to the WinGet pkgs repo. Still not sure if the scoop updater will pick it up as it hasn't found v0.2.2 yet...

@LGUG2Z commented on GitHub (Oct 16, 2024): I iterated on a bunch of changes I had to enable this in the whkd repo: https://github.com/LGUG2Z/whkd/blob/a04b9d5fc19e689efc488ec76f887806fda4ce11/.github/workflows/windows.yaml#L23 I managed to cut a release with both x86_64 and aarch64 binaries through the workflow and I've migrated largely the same approach here: https://github.com/LGUG2Z/komorebi/commit/92dd3169ca3f51d3856c532cec7b9448baa92405 I have set up a release dry run job which will run on every `master` commit to hopefully get ahead of any breaking workflow changes quickly in the future. From the whkd update experience it seems like the WinGet updater action will not pick up the new arch target so it will need to be updated manually when the action creates the PR to the WinGet pkgs repo. Still not sure if the scoop updater will pick it up as it hasn't found v0.2.2 yet...
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
0.1.36
apps-behaving-badly
bug
bug
cannot-reproduce
documentation
enhancement
github_actions
i-am-stuck
i-will-definitely-work-on-this
i-will-not-work-on-this
i-will-probably-work-on-this
komorebi
komorebi-bar
komorebic
performance
pull-request
Mirrored from GitHub Pull Request
 translation
No Label github_actions
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/komorebi#495
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?