fix: drive compile progress from ninja's [done/total] counter

[martipops]

The compile progress bar now follows ninja's [done/total] counter instead of counting output lines.

The old code bumped the bar a fixed amount per line and hit the compile cap (93%) after about 260 lines. That's fine on Linux, but macOS builds SDL and Aurora locally (around 760 ninja steps), so the bar sat at 93% for most of the build and looked hung. Now lines without a counter don't move the bar, it never goes backward, and it ignores malformed counters like [x/y] or [5/3].

I tested it by replaying a real 760-step log from an M-series Mac (76% halfway, 93% at the end, same end point as before) and by running junk lines through a throwaway harness. It doesn't share any files with #284, so either can merge first.

Summary by CodeRabbit

• Bug Fixes
  • Compilation progress now advances based on the build system’s reported completion count, providing a more accurate indication of how much work remains.
  • Progress no longer increases simply because output appears, so displayed progress better reflects actual compilation status.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: c951e9cb-a8c9-4b7f-90a1-d4de64ceca4a

📥 Commits

Reviewing files that changed from the base of the PR and between 6fa2473 and c64325a.

📒 Files selected for processing (1)

• Launcher/WiiCompiled.Setup.Linux/InstallProgress.cs

Included review availability: This review used your included allowance. Your plan provides up to 4 included reviews per hour; 1 remain after this review.

---

📝 Walkthrough

Walkthrough

Compile progress now uses valid Ninja [done/total] counters after the compile fraction is reached. Output lines continue to be sent to diagnostics.

Changes

Compile progress

Layer / File(s)	Summary
Parse and apply Ninja progress Launcher/WiiCompiled.Setup.Linux/InstallProgress.cs	TryParseNinjaProgress accepts counters that meet the stated format and value checks. Observe uses valid counters to scale progress from CompileFraction to 0.97, while continuing to report each line as a diagnostic.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Merge Risk: ⚪ Minimal · up to c6432

No actionable regression is established in the supported build paths; the progress change is ready to merge with normal checks.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 3 functions across 1 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: using Ninja's [done/total] counter to drive compile progress.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

• Fix all pre-merge checks with AI

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}