Skip to content

feat(xlings): show progress during silent bootstrap installs + fetching-index status#139

Merged
Sunrisepeak merged 1 commit into
mainfrom
feat/first-run-progress-visibility
Jun 21, 2026
Merged

feat(xlings): show progress during silent bootstrap installs + fetching-index status#139
Sunrisepeak merged 1 commit into
mainfrom
feat/first-run-progress-visibility

Conversation

@Sunrisepeak

Copy link
Copy Markdown
Member

Problem

On a first run, mcpp sits silently on Bootstrap ninja into mcpp sandbox (one-time) for a long time with zero feedback. The underlying xlings install runs as a direct std::system() call with all output redirected to the null device, and there is no spinner — so a slow, network-bound install looks frozen.

Fix (output-only — install order and mirror logic unchanged)

  1. Elapsed-time spinner during the silent direct install in install_with_progress: the blocking std::system(directCmd) now runs on a worker thread while the main thread paints an in-place braille spinner + elapsed seconds to stderr (\r ⠋ installing <target> (12s)), refreshing every ~200ms, then clears the line. Guarded by !quiet && mcpp::platform::terminal::is_tty() (reuses the existing is_tty() helper). The thread is always join()ed before computing the exit code; return-value logic is identical.

  2. "Fetching package index" status: ensure_init (the one-time, marker-gated first bootstrap step that precedes the first real install) now emits print_status("Fetching", "package index (one-time)") when not quiet, so the user knows the silent wait that follows is expected.

Scope / non-goals

  • Does not change the install order, the direct-vs-NDJSON fallback, or the mirror default — those are deferred.
  • Only src/xlings.cppm is touched. The TTY guard reuses the existing mcpp::platform::terminal::is_tty() (no new platform helper).

Verify

  • mcpp build — clean.
  • mcpp test — 22 passed; 0 failed.

@Sunrisepeak Sunrisepeak merged commit d237dee into main Jun 21, 2026
3 checks passed
Sunrisepeak added a commit that referenced this pull request Jun 21, 2026
* fix(build): self-heal stale build.ninja on 'missing and no known rule'

When a dependency package under the registry is reinstalled/moved but keeps
the same version string, the build fingerprint (which does not yet cover
registry dep state) is unchanged, so the cached build.ninja is reused.
Ninja then aborts with 'missing and no known rule to make it' and the build
hard-fails, forcing the user to run `mcpp clean` by hand.

Add that signature to is_stale_ninja_failure so try_fast_build drops to a
full graph regeneration (same invocation) instead of failing — the stale
graph is rewritten against the current dep state and the build proceeds.

(Folding registry dep state into the fingerprint to avoid the regen entirely
is a larger follow-up; see .agents/docs/2026-06-22 §T-j.)

* chore: bump version 0.0.57 -> 0.0.58

Release carrying the follow-up batch: scanner raw-string fix (#138),
first-run progress (#139), toolchain effective-resolution (#140),
doctor runtime-dep check (#141), and the build.ninja self-heal above.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant