Repository navigation
fix: exclude fuzz crate from cargo-dist Windows build targets #263
Description
Problem
The `release.yml` cargo-dist workflow fails on every release due to the `minigraf-fuzz` crate being compiled as part of the Windows (`x86_64-pc-windows-msvc`) build:
```
error: linking with `link.exe` failed: exit code: 1561
= note: LINK : fatal error LNK1561: entry point must be defined
error: could not compile `minigraf-fuzz` (bin "btree_page") due to 1 previous error
error: could not compile `minigraf-fuzz` (bin "datalog_parser") due to 1 previous error
```
libFuzzer targets use `#![no_main]` which the MSVC linker cannot handle — this is a fundamental incompatibility, not a code bug. The fuzz crate has never built on Windows.
The failure cascades: cargo-dist never creates the GitHub Release object, which causes the C Release and WASM/Mobile upload workflows to time out polling for it.
First observed at v1.0.0, recurred at v1.1.0.
Fix
Exclude `minigraf-fuzz` from the cargo-dist workspace member list so it is not compiled during release builds. In `Cargo.toml`:
```toml
[workspace]
members = [
# ... existing members ...
]
exclude = ["fuzz"]
```
Or configure cargo-dist to skip the fuzz crate via its `dist` config if the workspace exclusion has other side effects.
Impact
- Blocks: every release requires manually creating the GitHub Release and re-running upload workflows
- Affected workflows: `Release` (cargo-dist), `C Release`, `WASM Release Artifacts`
- Does not affect correctness — all artifacts publish successfully once the GitHub Release is created manually
Notes
- `release.yml` is cargo-dist owned; do not manually edit it. The fix should be in `Cargo.toml` workspace config or cargo-dist's own dist config (`[workspace.metadata.dist]`).
- The fuzz crate is `version = "0.0.0"` and is never published; excluding it from the release workspace is safe.
Activity
chore: release v1.1.1 — fix cargo-dist Windows build failure (#263)