5c36bdec28
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>
49 lines
2.4 KiB
Markdown
49 lines
2.4 KiB
Markdown
# Windows bundle resources
|
|
|
|
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.
|
|
|
|
## 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 |
|
|
|---|---|---|
|
|
| `vulkan-1.dll` | [LunarG Vulkan SDK](https://vulkan.lunarg.com/sdk/home) runtime installer, or copied from `C:\Windows\System32\vulkan-1.dll` on a machine with Vulkan-capable GPU drivers | whisper.cpp's Vulkan backend refuses to initialise without it |
|
|
| `libssl-3-x64.dll`, `libcrypto-3-x64.dll` | OpenSSL 3.x Windows build (e.g. shining-light installer) or copied from the user's `%SystemRoot%\system32` | reqwest → rustls transitively pulls these when TLS-backed downloads fail in CI; shipping them removes the "app fails to download model" class of bug |
|
|
|
|
The runtime falls back gracefully if any of these are missing at launch:
|
|
see `src-tauri/src/commands/models.rs::detect_active_compute_device`
|
|
and `emit_runtime_warnings` — the app will emit a `runtime-warning`
|
|
event with kind `vulkan-loader-missing`, downgrade the reported
|
|
`activeComputeDevice` to CPU, and keep running. The bundle is a
|
|
performance + reliability patch, not a load-bearing dependency.
|
|
|
|
## Why isn't this a script?
|
|
|
|
Licensing. We deliberately don't auto-fetch these DLLs from a CI job —
|
|
the LunarG SDK ships under the Apache 2.0 license but redistribution is
|
|
conditional on an acknowledgment, and the OpenSSL 3 bundling terms want
|
|
a source-availability note in the installer. Manual placement keeps the
|
|
redistribution legally clean per-release.
|
|
|
|
Brief reference: docs/whisper-ecosystem/brief.md item #12.
|