Skip to content

bug fix#31

Merged
juniorep merged 13 commits into
mainfrom
bbs-dev
Jul 16, 2026
Merged

bug fix#31
juniorep merged 13 commits into
mainfrom
bbs-dev

Conversation

@bbalouki

Copy link
Copy Markdown
Owner

No description provided.

bbalouki added 13 commits July 16, 2026 18:31
Switching the windows-latest matrix entry to windows-2022 didn't bust
the vcpkg/CMake build caches, since runner.os is "Windows" either way.
The job restored a CMakeCache.txt configured under the old runner's VS
2026 generator, which CMake then refuses to reuse under VS 2022:
"Does not match the generator used previously". Keying on matrix.os
(the concrete label) ties the cache to the actual toolchain instead.
The pinned baseline (5bf0c55, 2025-11-28) resolves benchmark to a
revision whose portfile passes "-Werror=old-style-cast" as a bare
CMake CLI argument instead of a compiler flag. CMake only recognizes
its own warning categories (dev, deprecated) for -Werror=<name>, so it
rejects the arg outright: "The warning category "old-style-cast" is
not known." This broke arm64-osx (and any triplet building benchmark
fresh) at configure time. Verified locally that the pinned commit's
portfile contains the bad OPTIONS entry, and that the new baseline's
benchmark (1.9.5) plus gtest/pybind11/python3 all install and build
cleanly.
Every job's vcpkg cache used a restore-keys prefix fallback. The
builtin-baseline bump changed vcpkg.json's content hash, missing the
exact-match key, and the fallback restored a stale $VCPKG_ROOT clone
predating that change. Its git history didn't contain the newly
pinned baseline commit, so lukka/run-vcpkg's "Set up vcpkg" step
failed outright (git exit 128) instead of falling back to a fresh
clone. This broke every job across every OS in the last run.

Dropping restore-keys means a cache miss just re-clones/rebuilds vcpkg
from scratch (a few extra minutes) instead of risking a wrong-vintage
clone that can't resolve the pinned baseline.
The previous baseline (bba3de2) was grabbed from a local vcpkg
checkout that was actually sitting on a personal working branch
(bbalouki-itch, tracking a fork) with local-only history layered on
top of upstream - that commit was never pushed to microsoft/vcpkg.
Every job's "Set up vcpkg" step failed identically (git exit 128,
"fatal: unable to read tree") because a genuine clone of
microsoft/vcpkg.git can never find a commit that only exists locally.

Verified this one for real: fetched origin/master directly, confirmed
bba3de2 is NOT an ancestor of it, then built the manifest (gtest,
benchmark) against 43643e1 in an isolated git worktree bootstrapped
from scratch, independent of any pre-existing local vcpkg state.
@bbalouki
bbalouki requested a review from juniorep July 16, 2026 20:43
@juniorep
juniorep merged commit 723de98 into main Jul 16, 2026
19 checks passed
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.

2 participants