🐢 Today I’m planning to add cross-compilation to the Xvc 0.6.13 branch to provide more platform support.
🐇 It looks like you first need to turn off this ghost text from the blink output. It makes writing insufferable.
🐢 Yep, let’s do that first.
🐇 Now, let’s restart Neovim.
🐢 I don’t know why blink.cmp doesn’t prioritize the emojis I use. Maybe we can just use #tor and #rab for ourselves.
🐇 I think over time it will learn that the emojis I defined in the snippets file should have higher priority, but let’s skip this for now. What do we need to do to add cross-compilation?
🐢 Maybe we can just make the completion menu wait a bit longer. It shows up almost instantly, and I want it to wait for a few more milliseconds.
🐇 Okay, let’s look at the config.
🐢 The configuration file doesn’t seem to have a key for this. Let’s search: blink.cmp.
🐇 I think the culprit is typo resistance; it causes better options to be pushed down: https://cmp.saghen.dev/configuration/reference#fuzzy
🐢 Let’s turn that off.
🐇 There is an error in the configuration file. I don’t know why it’s failing.
🐢 I added emojis to Espanso and checked the error message. The configuration I copied from their docs seems to be broken. The message is:
...share/nvim/lazy/blink.cmp/lua/blink/cmp/config/utils.lua:14: fuzzy.max_items: unexpected field found in configuration
I’ll just delete that line.
🐇 It still doesn’t prioritize snippets, but we can look into this later. Espanso seems to be a better tool for this anyway.
🐢 Yep. Let’s look into cross-compilation support for Rust.
🐇 The well-known option is cross.rs: https://github.com/cross-rs/cross
🐢 We can start with that. Installation is from the Git repository:
$ cargo install cross --git https://github.com/cross-rs/cross
Updating git repository `https://github.com/cross-rs/cross`
Updating git submodule `https://github.com/cross-rs/cross-toolchains.git`
Installing cross v0.2.5 (https://github.com/cross-rs/cross#4090beca)
...
Installed package `cross v0.2.5 (https://github.com/cross-rs/cross#4090beca)` (executables `cross`, `cross-util`)
🐇 Now we have the cross and cross-util commands. Cross-compilation requires Podman on Linux or Docker on macOS. Do we have Docker?
🐢 It looks like we don’t. Maybe we can just set up a remote build using Podman or GitHub Actions. I saw a crate for that yesterday; I remember saving it somewhere but can’t find it now. Searching again seems easier, which says something about my archival and retrieval habits.
🐇 Maybe later you can add some vector search capabilities to your archive—semantic search.
🐢 Yep, sometime later.
🐇 Now let’s search for “adding rust cross compilation to github actions.”
🐢 I found a link to the action: https://github.com/marketplace/actions/build-rust-projects-with-cross
Let’s look at the example:
jobs:
release:
name: Release - ${{ matrix.platform.os-name }}
strategy:
matrix:
platform:
- os-name: FreeBSD-x86_64
runs-on: ubuntu-20.04
target: x86_64-unknown-freebsd
skip_tests: true
- os-name: Linux-x86_64
runs-on: ubuntu-20.04
target: x86_64-unknown-linux-musl
- os-name: Linux-aarch64
runs-on: ubuntu-20.04
target: aarch64-unknown-linux-musl
- os-name: Linux-riscv64
runs-on: ubuntu-20.04
target: riscv64gc-unknown-linux-gnu
- os-name: Windows-x86_64
runs-on: windows-latest
target: x86_64-pc-windows-msvc
- os-name: macOS-x86_64
runs-on: macOS-latest
target: x86_64-apple-darwin
# more targets here ...
runs-on: ${{ matrix.platform.runs-on }}
steps:
- name: Checkout
uses: actions/checkout@v3
- name: Build binary
uses: houseabsolute/actions-rust-cross@v0
with:
command: ${{ matrix.platform.command }}
target: ${{ matrix.platform.target }}
args: "--locked --release"
strip: true
- name: Publish artifacts and release
uses: houseabsolute/actions-rust-release@v0
with:
executable-name: ubi
target: ${{ matrix.platform.target }}
🐇 We can just convert the current configuration to this and see if it works.
🐢 Let’s do that. I created .github/workflows/release.yml and will update it.
🐇 Let’s check the results with gh:
$ gh -R iesahin/xvc run list
completed failure v0.6.13 Release v0.6.13 pull_request 12525070531 34s 2024-12-28T08:17:28Z
🐢 It says the release has completed.
$ gh -R iesahin/xvc run view 12525070531
X v0.6.13 Release iesahin/xvc#263 · 12525070531
Triggered via pull_request about 3 minutes ago
JOBS
X Release - FreeBSD-x86_64 in 12s (ID 34936257653)
✓ Set up job
✓ Checkout
X Build binary
- Publish artifacts and release
✓ Post Build binary
✓ Post Checkout
✓ Complete job
...
Now let’s look at the failure:
$ gh -R iesahin/xvc run view 12525070531 --log-failed
🐇 Change the order and see what happens. Maybe we should first succeed in a non-cross-compilation build.
$ gh -R iesahin/xvc run list
completed failure v0.6.13 Release v0.6.13 pull_request 12525178664 35s 2024-12-28T08:34:18Z
...
$ gh -R iesahin/xvc run view 12525178664 --log-failed
...
🐢 It’s the same error. The usage example is actually much more sophisticated.
🐇 The issue is that we’re asking for command from the matrix, but the matrix doesn’t define it. That’s the second time today an example from the documentation has failed. I’ve added command for each platform. We can also add separate features this way to make platform-specific functionality work.
🐢 Agreed. Let’s look at it once more.
$ gh -R iesahin/xvc run list | rg Release | head -n 1
completed failure v0.6.13 Release v0.6.13 pull_request 12525253982 41s 2024-12-28T08:46:23Z
$ gh -R iesahin/xvc run view 12525253982 --log-failed
...
Release - macOS-x86_64 Build binary 2024-12-28T08:46:44.8464010Z [1m [31merror [0m [1m: [0m the lock file /Users/runner/work/xvc/xvc/Cargo.lock needs to be updated but --locked was passed to prevent this
🐇 Ah, that’s a different error. Let’s remove the --locked flag and retry.
$ gh -R iesahin/xvc run list | rg Release | head -n 1
completed failure v0.6.13 Release v0.6.13 pull_request 12525289176 1m8s 2024-12-28T08:53:23Z
🐢 We’re finally starting to get some good news. Now we’re getting OpenSSL errors. We need feature flags for these platforms or to specify where OpenSSL is. Let’s add bundled-openssl to the failed ones. We also need bundled-sqlite for Windows binaries.
gh -R iesahin/xvc run list | rg Release | head -n 1
completed failure v0.6.13 Release v0.6.13 pull_request 12525354179 3m9s 2024-12-28T09:04:55Z
🐇 It looks like the Changes.md file is missing, and it can’t upload the binaries as a release because of this. I’ll set the changes file to CHANGELOG.md.
🐢 It’s weird to fail because of that. I think we should report these errors and possibly send a PR to make that file optional.
gh -R iesahin/xvc run list | rg Release | head -n 1
in_progress v0.6.13 Release v0.6.13 pull_request 12525449368 1m38s 2024-12-28T09:18:40Z
...
✓ Release - macOS-x86_64 in 2m39s (ID 34937017695)
✓ Release - macOS-aarch64 in 2m42s (ID 34937017787)
..
ARTIFACTS
xvc-macOS-x86_64.tar.gz
xvc-macOS-arm64.tar.gz
🐢 It looks like Linux-riscv64 has OpenSSL compilation errors. I think we can skip this platform for now. The goal was to add aarch64 for macOS, and that seems to have succeeded.
gh -R iesahin/xvc run list | rg Release | head -n 1
completed failure v0.6.13 Release v0.6.13 pull_request 12525504079 3m24s 2024-12-28T09:26:43Z
...
X Release - Linux-x86_64 Build binary 2024-12-28T09:29:16.2262518Z [0m [1m [38;5;9merror[E0308] [0m [0m [1m: mismatched types [0m
...
🐢 It looks like Linux-x86_64 doesn’t support reflinks. Maybe we can make reflinks an optional feature and add it specifically to macOS and Windows targets.
🐇 I’ve removed reflink from the default features. This is a breaking change, but fortunately we don’t have many users who will be affected by it.
Let’s check the results once more.
gh -R iesahin/xvc run list | rg Release | head -n 1
completed failure v0.6.13 Release v0.6.13 pull_request 12525597866 3m39s 2024-12-28T09:42:44Z
🐢 Now turn off the NetBSD target as well.
🐇 FreeBSD and Linux-x86_64 targets are building. Let’s see why the ARM Linux targets are failing.
gh -R iesahin/xvc run list | rg Release | head -n 1
completed failure v0.6.13 Release v0.6.13 pull_request 12525643284 4m46s 2024-12-28T09:52:04Z
🐇 It looks like those targets don’t have libsqlite3 installed. Let’s add bundled-sqlite to these targets too.
gh -R iesahin/xvc run list | rg Release | head -n 1
completed failure v0.6.13 Release v0.6.13 pull_request 12525734325 4m11s 2024-12-28T10:07:36Z
🐢 Adding Android as a target didn’t work. Let’s remove it for now; it seems to require more work.
🐇 I think we’ll eventually move to using Xvc to distribute binaries. We could build the Android binary on Termux and link it on the releases page or push it as a release artifact.
🐢 I need to learn more about GitHub releases. If we can add artifacts to the release, maybe we can do some of this work locally.
🐇 We can start by looking at the capabilities of gh commands.
🐢 It looks like it’s possible to upload assets to releases. Let’s check how that works.
gh release upload --help
🐇 So basically, we can just upload files to tags. We can list releases and work with them like anything else.
gh -R iesahin/xvc release list
And we can delete releases:
for r in v0.4.2-alpha.8 v0.4.2-alpha.7 v0.4.2-alpha.6 v0.4.2-alpha.5 v0.4.2-alpha.0 v0.4.1-alpha.0; do
gh -R iesahin/xvc release delete "${r}"
done
🐢 Now let’s list them again.
gh -R iesahin/xvc release list
🐇 The latest one has failed again.
X Failed to CreateArtifact: Received non-retryable error: Failed request: (409) Conflict: an artifact with this name already exists on the workflow run
🐢 It looks like we’re coming to the end of this session. Under what conditions will we create a release?
🐇 I think it’s better to release only non-alpha tags.
🐢 Then the rule in the workflow will be something like:
on:
workflow_dispatch:
push:
tags:
- "v*.*.*"
- "!v.*.*-alpha.*"
🐇 And now we have this result:
✓ v0.6.13 Release iesahin/xvc#263 · 12533498361
Triggered via pull_request about 21 minutes ago
JOBS
✓ Release - FreeBSD-x86_64 in 4m14s
✓ Release - Linux-x86_64 in 4m3s
✓ Release - Linux-aarch64 in 4m50s
✓ Release - Windows-x86_64 in 8m47s
✓ Release - Windows-aarch64 in 6m42s
✓ Release - macOS-x86_64 in 2m37s
✓ Release - macOS-aarch64 in 2m36s
🐢 Nice! Let’s check the release list.
gh -R iesahin/xvc release list
🐇 Why is there no “latest” release?
🐢 We have to tag it first.
🐇 Ah, right. Let’s tag it then.
🐢 I’ve pushed the changes and tagged them with v0.6.13-alpha.5.
🐇 I think it’s possible to make a release today.
🐢 It looks like it, yes.
🐇 We can merge the PR and tag it. Then everything should work.
🐢 We need some cleanup in the YAML files, though.
🐇 We can leave that for the next release.
gh -R iesahin/xvc run list
in_progress v0.6.13 Rust-CI v0.6.13 pull_request 12533690474 9m18s 2024-12-29T08:02:29Z
completed success Release Release v0.6.13-alpha.5 push 12533689099 9m11s 2024-12-29T08:02:19Z
🐢 Now we have another failure in the regular CI. Let’s look at it.
🐇 The issue seems to be in the doc tests:
- Total #: 8 Workspace Size: 276 Cached Size: 19
+ Total #: 8 Workspace Size: 278 Cached Size: 19
🐢 These tests are brittle, but they provide valuable information. Let’s fix it and push again.
🐇 Done. We can also remove some of the watches that produce so many logs.
🐢 I’m a bit ambivalent about them. I thought we could use these watches when debugging, but experience has shown that we need more granular watches during debugging and almost never use these otherwise. Let’s remove some of them.
🐇 We can increase the output for certain commands, but the tracing output doesn’t help much in regular runs. If Xvc gets popular enough that we can’t cope with bug reports, we can always add more watches.
🐢 Another option is to exclude the watch code from the release build, but that won’t change anything for our debug cycles.
🐇 I think removing them is a fair trial. We can always put them back when debugging.
🐢 Watches could also produce regular output instead of tracing. That way we won’t forget to remove them.
🐇 Ah, yep, that’s a good option too.
🐢 We can have a trace! macro similar to the current one for user consumption, and a watch! macro that sends output to stderr.
🐇 Good idea. Let’s do that in the next release.
🐢 Let’s check the tests before pushing this cleanup.
gh -R iesahin/xvc run list
completed success v0.6.13 Rust-CI v0.6.13 pull_request 12533993607 13m49s 2024-12-29T08:47:50Z
🐇 CI succeeded, and the release didn’t run. Let’s do some more cleanup.
gh -R iesahin/xvc run list
in_progress v0.6.13 Rust-CI v0.6.13 pull_request 12534416152 43s 2024-12-29T09:57:02Z