Skip to content

0.15.1: a vcpkg installation waits for another one of the same root - #33

Merged
speak-agent merged 1 commit into
mainfrom
fix/vcpkg-wait-for-lock
Sep 26, 2026
Merged

speak-agent merged 1 commit into
mainfrom
fix/vcpkg-wait-for-lock

Conversation

@speak-agent

Copy link
Copy Markdown
Member

Under 0.15.0, GalTranslPP (Windows) failed in mcpp build -p GPPCLI. Two workspace members install one vcpkg root, and their actions ran at once:

vcpkg-running.lock: error: failed to take lock, another vcpkg may be running against the same directory

0.13.0 and 0.14.0 serialised the two installations with their own lock, inside mcpp-deps. Since 0.15.0 the action is vcpkg itself, and vcpkg waits for its root lock only when asked to. The action now passes --x-wait-for-lock.

Measured locally with two concurrent vcpkg install runs on one root: with the flag, both exit 0 (one reports "waiting to take filesystem lock"); without it, one exits 1. The vcpkg-workspace criterion now also requires the flag in both members' plans. Local runs of vcpkg-consumer and vcpkg-workspace pass. The docs statement that the lock alone serialised the installations is corrected.

@speak-agent
speak-agent merged commit 25d577d into main Sep 26, 2026
3 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