feat: initial winget workflow

[jqnatividad]

for #4236

WIP. Will have to wait after the release 22.x

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[jqnatividad]

Two findings that surfaced while investigating #4236. Both are pre-existing and out of scope for this PR — filing them here so they aren't lost.

---

1. The Windows release zip ships .pdb debug symbols

qsv-21.1.0-x86_64-pc-windows-msvc.zip is 346 MB. Reading its central directory (HTTP range request on the last 60 KB of the published asset, no full download) gives:

qsv.exe        qsv.pdb
qsvlite.exe    qsvlite.pdb
qsvmcp.exe     qsvmcp.pdb
qsvp.exe       qsvplite.exe   qsvpmcp.exe
qsvpy311.exe   qsvpy312.exe   qsvpy313.exe
qsvpy_rust_version_info.txt   README

The .pdb files get swept in by the glob at .github/workflows/publish.yml:282:

cp -v target/${{ matrix.job.target }}/$d/qsv* qsv-${{ ... }} 2>/dev/null || true

The line above it already prunes *.d, but nothing excludes *.pdb. This looks unintended: [profile.release] sets debug = false and strip = true (Cargo.toml:130,135), and release-luau inherits both — the only profile with strip = false is release-samply, which publish never uses. So why a PDB is produced at all despite debug = false is worth a look (PGO instrumentation on MSVC is one candidate, but qsvlite/qsvmcp aren't PGO-built and have PDBs too). Either way the packaging fix is a one-liner — narrow the glob.

For contrast, qsv-21.1.0-aarch64-pc-windows-msvc.zip is 47 MB. I haven't measured the per-file split, so I can't say how much of the 346 MB is PDBs versus the six extra qsvp*/qsvpy* binaries.

Relevant to winget: this 346 MB archive is what winget install datHere.qsv will pull, and installer size is the main Error-Analysis-Timeout risk during winget-pkgs validation.

---

2. README.md:314 overstates how the qsvp* portables differ

There are "portable" subvariants of qsv available with the "p" suffix - qsvp, qsvplite and qsvpdp. These subvariants are compiled without any CPU features enabled.

publish-portable.yml is also named "Publish Portable - no CPU features". But in the current workflows:

• addl-rustflags is empty for x86_64-pc-windows-msvc in both publish.yml and publish-portable.yml — neither sets -C target-cpu or -C target-feature.
• scripts/build-pgo.sh and scripts/pgo-train.sh don't inject one either (target-cpu appears in those files only in a comment and in benchmarks.sh docs).
• The only actual difference is that publish-portable.yml has no PGO step; it builds the same binaries and renames them with the p prefix.

So both builds are already rustc-baseline x86-64, and README.md:167 ("We do not enable CPU optimizations on prebuilt binaries on x86_64 platforms") is the accurate statement. Line 314 promises a difference that no longer exists in the build config.

That doesn't make the portables useless — any residual SIGILL exposure comes from dependency-level SIMD runtime dispatch (polars et al.), and a non-PGO build can plausibly dodge it. But the wording should describe what the workflow actually does. The workflow's own name is part of the drift.