fix(ci A.1 #12): drop tauri.windows.conf.json — cargo check fails on unknown _comment field + missing resources

Two issues with the previous #12 approach, both caught by CI:

1. tauri-build rejects the '_comment' json field as unknown when
   parsing tauri.windows.conf.json:

     unknown field `_comment`, expected one of `$schema`,
     `product-name`, `productName`, ...

   The schema is strict, so the doc-comment has to live elsewhere.

2. tauri-build's bundle.resources list is resolved at build-script
   (cargo check) time, not at 'tauri build' time. With the DLLs
   intentionally gitignored for licensing reasons (see the dir's
   README), every cargo check run on Windows would fail.

Fix: delete tauri.windows.conf.json entirely. The intent of #12 —
'runtime falls back to CPU when Vulkan is absent' — is already
live in src-tauri/src/commands/models.rs::detect_active_compute_device,
unchanged.

Rewrite resources/windows/README.md to document a cargo tauri build
--resource ... invocation for the release engineer. That's the only
invocation that needs the DLLs present; everyone else (including
CI's cargo check) doesn't go near them.

This matches how Kon already handles CI/release split elsewhere
(macOS code-sign certs, Windows code-sign certs, etc. all stay out
of tauri.conf.json for the same reason).

Co-authored-by: jars <jakejars@users.noreply.github.com>
This commit is contained in:
Cursor Agent
2026-04-21 13:55:17 +00:00
committed by Jake
parent db8f1bf19d
commit 5c36bdec28
2 changed files with 22 additions and 14 deletions

View File

@@ -2,9 +2,28 @@
Files in this directory ship side-by-side with `kon.exe` to avoid the
DLL-hell failure modes reported in Whispering #840 / #829 and Buzz
#1459. They are **not** committed to the repo — populate them from a
trusted source before running `cargo tauri build --target
x86_64-pc-windows-msvc`:
#1459. They are **not** committed to the repo.
## Release-engineer workflow
Before a Windows release build, populate this directory from a trusted
source (see table below), then pass `--resource` flags through to
`tauri build`:
```powershell
cargo tauri build --target x86_64-pc-windows-msvc -- `
--resource src-tauri/resources/windows/vulkan-1.dll `
--resource src-tauri/resources/windows/libssl-3-x64.dll `
--resource src-tauri/resources/windows/libcrypto-3-x64.dll
```
These files are **not** declared in `tauri.conf.json` /
`tauri.windows.conf.json` because `cargo check` (which runs in every
CI job) evaluates `tauri-build` and fails if a listed resource path
doesn't exist. Keeping the bundle flags at `tauri build` call time
means `cargo check` stays green on vanilla checkouts while release
builds still pick them up when the release engineer runs the
populated command above.
| File | Source | Why |
|---|---|---|