Inserting vcpkg-tool 2026-09-26 into Visual Studio caused @sean-mcmanus
's GPT 6 Sol code review bot to re-review some previous changes. It
said:
> ✨Copilot (agent227): [Minor] The new x-update-baseline diff output in
[vcpkg-tool PR 2057](https://github.com/microsoft/vcpkg-tool/pull/2057)
builds its [version
snapshot](https://github.com/microsoft/vcpkg-tool/blob/51bf87ca6e9bf3e622d84ff323bd202ab1ca0c0b/src/vcpkg/commands.update-baseline.cpp#L63-L81)
with versions.emplace(action.spec.name(), ...), so a host and target
action for the same port collapse to whichever entry is visited first.
The versioned planner supports both specs in one action plan (see its
[host-tool
test](https://github.com/microsoft/vcpkg-tool/blob/51bf87ca6e9bf3e622d84ff323bd202ab1ca0c0b/src/vcpkg-test/dependencies.cpp#L2083-L2159)
) and resolves their version constraints separately. If only the
discarded triplet's selected version changes on an update, the command
can print There were no changes in the ports. despite a real
dependency-version change. Could the snapshot key/report include the
triplet when both variants are present? This is a reporting issue; the
baseline update itself remains intact.
Addressing this is the majority of this change: if host/target triplet
diverge on selected version, we now print the whole spec rather than
just the port version.
I would normally describe the edge cases handled here, but I think the
unit tests added in src/vcpkg-test/commands.update-baseline.cpp are a
better place to start.
> ✨Copilot (agent227): [Minor] The bundled release adds O_CLOEXEC to the
POSIX lock handle, but [its new regression
test](https://github.com/microsoft/vcpkg-tool/blob/51bf87ca6e9bf3e622d84ff323bd202ab1ca0c0b/src/vcpkg-test/files.cpp#L1141-L1177)
calls lock.reset() before attempting the second lock. That destructor
explicitly calls
[flock(LOCK_UN)](https://github.com/microsoft/vcpkg-tool/blob/51bf87ca6e9bf3e622d84ff323bd202ab1ca0c0b/src/vcpkg/base/files.cpp#L4273-L4280)
, releasing the shared open-file-description lock even when the exec'd
child inherited the descriptor. I reproduced the second acquisition
succeeding both with and without close-on-exec, so the test would pass
after removing the production flag. Could the test let the lock-owning
parent exit without explicitly unlocking while the exec'd child is still
alive, then check acquisition from a separate process? That would
actually protect the file-lock fix in this release.
This test was a sticking point back in the review; as far as I can tell
because the actual lock object is inherited by the child process there's
no way to close our copy without also closing the child's copy. All
suggestions to test this better go WAY out of contract trying to add
stuff to cough up the `fd` and similar which I do not want to do, so I
just deleted the meaningless test.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
While documenting the Apple platform expression added for #2121 in
MicrosoftDocs/vcpkg-docs#612, the platform-expression reference exposed
that the existing xbox identifier did not match `VCPKG_TARGET_IS_XBOX`.
The CMake definition recognizes Xbox only for the desktop Windows system
name (empty or undefined) with a non-empty `VCPKG_XBOX_CONSOLE_TARGET`.
Platform expressions previously checked only the console target, so UWP
and unrelated target systems could incorrectly satisfy xbox.
Apply both conditions and cover missing, empty, desktop Windows, UWP,
and non-Windows system-name cases.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: a19bbe2f-47e6-474d-be82-2550f8a1aafa
We got a report complaining that vcpkg-artifacts can misbehave if you
ask for a branch name with funny command line implications.
vcpkg-artifacts is slated for removal (see
https://github.com/microsoft/vcpkg-tool/pull/2032 ) but is still around
due to one important customer still using it for now.
If this only affected vcpkg-artifacts I would have made no changes, but
I also asked GPT 5.6 Sol to audit for other examples because we invoke
git all over the place and it found some places that could be better.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 9880d476-bed1-4a5c-b356-b02bbd419d90
* Visual Studio MicroBuild are removing VSEngSS-MicroBuild2022-1ES ,
switch to VSEng-MicroBuildVSStable
* Update SDL pools to Server 2025. (Can't believe I missed that we still
had Server 2022 dependencies before!)
* NodeJS 24.x
* NuGet 7.9
* Build on macOS 26, target macOS 14 "Sonoma". Note that macOS 14 is the
oldest version of macOS currently in support from Apple according to
https://endoflife.date/macos
This is https://github.com/microsoft/vcpkg-tool/pull/1485 /
https://github.com/microsoft/vcpkg-tool/pull/1392 now that we have the
DiagnosticContext infrastructure to make it not painful.
Run up to eight external object-storage downloads concurrently while
respecting lower VCPKG_MAX_CONCURRENCY values. Each worker writes to its
own result slot and FullyBufferedDiagnosticContext; after all workers
finish, diagnostics are replayed on the calling thread in action order,
avoiding concurrent console I/O.
Add a bounded execute_in_parallel overload without changing existing
callers, plus regression coverage for its concurrency ceiling.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This is a psuedo-alternative to #1980 or at least to get similar results
as intended there.
I used GPT 5.5 in authoring this change.
```console
PS C:\Dev\vcpkg-tool\src> C:\Dev\vcpkg-tool\out\build\Win-x64-Debug-WithArtifacts\vcpkg.exe x-update-baseline --dry-run --vcpkg-root C:\Dev\vcpkg
Fetching registry information from https://github.com/microsoft/vcpkg (HEAD)...
updated registry 'https://github.com/microsoft/vcpkg': e03dc9b29710050cd1018bc5674688108658d327 -> 42e4e33e1505c9f47b58c21e0f557c1571b751ee
Updating baselines has resulted in the following version updates:
Direct dependencies:
curl: 8.20.0#1 -> 8.21.0#1
Transitive dependencies:
zlib: 1.3.2 -> 1.3.2#1
```
This required a complete reimplementation of the SBOM resource tracking
feature: the alternative would have been implementing an entire CMake
file format parser which would have been excessive.
Instead, we change the `vcpkg_from_Xxx` functions themselves to record
this information because CMake has already expanded the values for them.
They form the JSON objects themselves and build_info.cmake writes out
the results.
I had to edit all the from_Xxx functions to do this which effectively
makes this change a world rebuild. As a result I also changed every
other file in scripts/ to have LF line endings, except for those which
have embedded digital signatures which would be damaged by doing so.
Over in the "registry" repo:
build_info.cmake: Write the SPDX resources
ports.cmake: Include the new helper
vcpkg_download_distfile.cmake: Split into a z_ helper which does the raw
thing, and the "public" version which also records SPDX resource
information.
Elsewhere: Use the internal helper when not intending to add SPDX
resources, add SPDX resource records, remove meaningless QUIET
Before (note meaningless `${SQLITE_VERSION}`):
```json
{
"SPDXID": "SPDXRef-resource-0",
"name": "sqlite-autoconf-${SQLITE_VERSION}.tar.gz",
"packageFileName": "sqlite-autoconf-${SQLITE_VERSION}.tar.gz",
"downloadLocation": "https://sqlite.org/2026/sqlite-autoconf-${SQLITE_VERSION}.tar.gz",
"licenseConcluded": "NOASSERTION",
"licenseDeclared": "NOASSERTION",
"copyrightText": "NOASSERTION",
"checksums": [
{
"algorithm": "SHA512",
"checksumValue": "355a8db490ec2a68c2801644e56178a26416c355792586a6c1c904de116e26f8602bc344e7172181c9d92c4c9e696319243e16405460fad87b23ee997a3ef9da"
}
]
}
```
After:
```json
{
"SPDXID": "SPDXRef-resource-0",
"checksums": [
{
"algorithm": "SHA512",
"checksumValue": "355a8db490ec2a68c2801644e56178a26416c355792586a6c1c904de116e26f8602bc344e7172181c9d92c4c9e696319243e16405460fad87b23ee997a3ef9da"
}
],
"copyrightText": "NOASSERTION",
"downloadLocation": "https://sqlite.org/2026/sqlite-autoconf-3530300.tar.gz",
"licenseConcluded": "NOASSERTION",
"licenseDeclared": "NOASSERTION",
"name": "sqlite-autoconf-3530300.tar.gz",
"packageFileName": "sqlite-autoconf-3530300.tar.gz"
}
```
As part of improving the code review skills (
https://github.com/BillyONeal/vcpkg/tree/add-review-skills ) we wanted
to add an automated check that new ports follow the "don't add a usage
file if the generated usage is correct" rules, but testing that was
annoying as one had to manually remove the usage file and reinstall the
port to test before.
The command `print-usage` should make that easier. It prints what the
current usage text is, and `--generated` can be passed to ignore the
usage file and print what the generated usage *would* be if the user
didn't supply a custom one.
Also adds a mechanism where a port can `file(TOUCH
"${CURRENT_PACKAGES_DIR}/share/${PORT}/usage-accurate")` to remove the
"# this is heuristically generated, and may not be correct" part of the
generated usage. This will resolve the main reason people (including me)
were mistakenly adding custom usage.
MAI-Code-1-Flash, GPT 5.4, and GPT 5.5 were used in authoring some of
the changes here (but did not write this message).
When a port is marked =fail in the feature baseline and has a
self-dependency via a feature (e.g., `cpprestsdk[brotli]` depends on
`cpprestsdk[compression]`), the install plan for a later feature test of
the same port may resolve to the same ABI as an earlier failed test.
Without this fix, the code would match that ABI in `known_failures` and
incorrectly report the test as an unexpectedly cascading failure rather
than recognizing it as a build failure.
The fix filters out install actions whose `package_spec` matches the
spec being tested, since those are part of testing the port itself, not
external dependencies.
Adds regression test vcpkg-self-fail port and assertions in
test-features.ps1.
Most of this was written by Claude Opus 4.7.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This is a followup to https://github.com/microsoft/vcpkg-tool/pull/1988/
where I observe that the same type of defect applies to the "normal" way
vcpkg gets environment variables.
Ensure that empty vs. unset is preserved correctly, enable use of the
small string optimization for wstring, and audit all callers.
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
In https://github.com/microsoft/vcpkg/pull/51431 I observed that
`x-add-version --all` does not remove removed entries which seems
incorrect. This changes `--all` to completely regenerate the baseline
file. It also changes `x-add-version` to create the file if it doesn't
exist.
Drive by refactor: deduplicate all the "file not found" std::errc
comparisons.
Related: https://github.com/microsoft/vcpkg/pull/51149
I came here to debug an infinite loop I observed in that PR whose root
cause was the "archive" name not ending in ".7z.exe". Which turned out
to be a problem in that JSON, but the scaffolding I added here for it is
still relevant.
I also deleted all the MSI extraction stuff because as far as I can tell
that is unused as of https://github.com/microsoft/vcpkg-tool/pull/1477
* Adopt libfuzzer to replace AFL.
libfuzzer is more efficient because it does in-process fuzzing. This also allows fuzzing with the tools that come in the box with Visual Studio. libfuzzer makes each parser test into its own separate executable.
Other changes:
* All Unicode handling had to be hardened to not just terminate the process if the input isn't valid UTF-8. As a result terminating operations like ++ on Utf8Decoder were removed and all callers were changed to call next() and handle errors.
* The JSON parser constantly hit stack overflows which terminated the process and stopped fuzzing. To resolve that, introduced a max recursion depth of 200.
* Accidentially left in a __debugbreak
* Drop unnecessary _cdecl
* Avoid some compiler warnings.
* Use VCPKG_BUILD_FUZZING on Linux.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Alternative to: https://github.com/microsoft/vcpkg-tool/pull/1949
Also recorded in https://github.com/microsoft/vcpkg/pull/48797#issuecomment-3645291162
Repeating what @JavierMatosD said from that PR stating the problem:
>When a port is marked =fail in ci.baseline.txt and --skip-failures is active, the port was previously added to the exclusions map before feature resolution. This had two consequences:
>
>1. When a dependency is statically unsupported for the triplet, the tool incorrectly reported a regression for =fail ports that cascaded. The planner knows at plan time that the dependency graph is unsatisfiable
>2. Excluding =fail ports from the plan changed which features were resolved for shared dependencies. A port could pass in PR (fewer features active) but cascade in CI.
To clarify (1), emitting a diagnostic is correct but we claimed that it was a cascade when it's actually a direct failure. Related: https://github.com/microsoft/vcpkg-tool/pull/1955
* include/vcpkg/fwd/build.h et al.
Add new states to represent *why* something cascaded and let us distinguish between "static" cascades (where the cascade is implied by the baseline or by "supports") and "dynamic" cascades (where the cascade happens because a build fails later)
* include/vcpkg/ci-baseline.h + src/vcpkg/ci-baseline.cpp
Rename failures/success to fail/pass because those are the words we use in ci.baseline.txt.
Rename "cidata" to "ci_data" because it was making spell check angry at me.
Only put =skip things in the exclusion map and always record =fail as an expected_fail. (SkipFailures is now handled elsewhere)
* src/vcpkg/commands.ci.cpp
Split SkipReason::Cascade into BaselineCascade and SupportsCascade
In compute_pre_build_statuses, emit 's-fail' for "skipped expected to fail" for --skip-failures. Rather than control coupling with a bool here, callers when --skip-failures is off just pass an empty vector of skipped failures.
In prune_entirely_known_action_branches, use a switch for looking at the "known" status. Remove the attempts to avoid inserting dependencies; in the current world order if 'forbidden' dependencies made it into the plan calculate_ci_specs failed to remove those.
In calculate_ci_specs, reorder all the "supports" checking before any of the baseline checking. This allows later reporting stages to see inconsistencies between the baseline and supports clauses without reevaluating supports clauses.
* azure-pipelines/e2e-assets/ci-skipped-ports/baseline.fail.txt: The comment says "fail is skip here" but that's no longer true. Changed those to actually be =skip to make that test otherwise not need to change.
* azure-pipelines/end-to-end-tests-prelude.ps1: Add Run-VcpkgAndCaptureBoth
* azure-pipelines/end-to-end-tests-dir/ci.ps1:
For tests that were duplicating just to get stdout and stderr, use Run-VcpkgAndCaptureBoth.
Update expected count blocks for CASCADED_DUE_TO_MISSING_DEPENDENCIES being split.
Add test that dependencies of failure baselines still contribute features under --skip-failures . This is specifically what https://github.com/microsoft/vcpkg/pull/48797#issuecomment-3645291162 was talking about
Add test for every "REGRESSION:" line to make sure they aren't bogus.
Resolves https://github.com/microsoft/vcpkg-tool/issues/1902
The fmt folks did a lot of work to make their compilation time go down quite a bit so we shouldn't need the forward declaration any longer. Build time goes up a small amount but not enough to justify keeping the forward declarations and inline namespace hoops present.
On my 9970X test machine, a clean rebuild:
Before: [driver] Build completed: 00:00:21.350
After: [driver] Build completed: 00:00:21.562
GPT 5.4-Medium did much of the work here.
To the best of my understanding --exclude was added as part of implementing baseline support back when parsing that file was done in PowerShell and translated into a command line switch. And --host-exclude probably got added because we had a shared function that did this. This has led to the whole product calling this an "exclusion" despite all user facing interaction with this being "skip".
Delete --exclude and adopt "skip" as the name for this across the product.
Also use Throw-IfNonContains et al. so that test failures print the expected/actual output.
Before:
```
never-built-unsupported:x64-windows: unsupported
never-built-unsupported-feature:x64-windows: cascade
never-built-unsupported-feature-default:x64-windows: cascade
never-built-unsupported-host:x64-windows: unsupported
never-built-unsupported-host-feature:x64-windows: cascade
```
[...]
```
never-built-unsupported:cross: unsupported
never-built-unsupported-feature:cross: cascade
never-built-unsupported-feature-default:cross: cascade
never-built-unsupported-host:cross: cascade
never-built-unsupported-host-feature:cross: cascade
```
Afterwards these are all 'unsupported'.
Feedback from the Windows build lab is that they run several concurrent vcpkg manifest installs in ways that don't actually conflict. However, our file locking for manifest mode put the file lock in VCPKG_ROOT, a false conflict for manifest mode builds.
This change moves that lock into the installed tree itself so that only actually conflicting installs will lock or block.
Drive by changes:
* "tools" is removed from z-print-config as that forced extra API surface onto vcpkg paths for a meaningless test.
* re-sorted contractual-constants.h
* try_take_exclusive_file_lock double-nested optional removed
* shorten_text moved from "vcpkglib.h" to "strings.h"
* vcpkglib.* renamed to installeddatabase.*
* database_load_collapse renamed database_sync
* write_update renamed database_write_update
* The on-disk layout of the installed tree is now documented in installedpaths.h
* VcpkgCmdArguments::do_not_take_lock is now unnecessary as the lock is targeted at operations that actually affect the installed tree rather than everything.
* blocks concurrent modification of an installed tree in 'classic' mode, not only manifest mode
* Improve shorten_text to not visit more of the input than necessary.
Terrpain is an internal Microsoft network isolation tool frequently used with `x-script` asset caching settings. Allow environment variables used to pass authentication data like which tentant to use to it.
In https://github.com/microsoft/vcpkg-tool/pull/1842/ I broke portsdiff and z-changelog because the previous behavior checked only if git cat-file -t succeeded, not whether the target was actually a commit. By "fixing" that to actually check for commit that breaks tag inputs.
Using -e and ^{commit} was suggested by gpt-5.3-codex but it was unable to make the other changes.
Demonstration:
```console
PS C:\Dev\vcpkg> .\vcpkg.exe z-changelog 2026.01.16
error: Invalid commit id: 2026.01.16
PS C:\Dev\vcpkg> C:\Dev\vcpkg-tool\out\build\Win-x64-Debug-WithArtifacts\vcpkg.exe z-changelog bogus
error: Invalid commit id: bogus
note: "C:\Program Files\Git\cmd\git.exe" -C "C:\Dev\vcpkg" -c core.autocrlf=false cat-file -e "bogus^{commit}" failed with exit code 128
fatal: Not a valid object name bogus^{commit}
PS C:\Dev\vcpkg> C:\Dev\vcpkg-tool\out\build\Win-x64-Debug-WithArtifacts\vcpkg.exe z-changelog 2026.01.16
#### Total port count: 2765
#### Total port count per triplet (tested): LINK
.
.
.
```
I'm going through ~1200 failures in https://github.com/microsoft/vcpkg/pull/45331 and the diagnostics are ordered by the size of the ActionPlan even though generally baseline settings for a given port must be considered together which is inconvenient.
This tries to fix failures reported in https://github.com/microsoft/vcpkg-tool/actions/runs/20175286709
1. macOS-26 takes 15 times as long when CodeQL is turned on which causes the overall run to exceed GitHub's 2 hour time limit. I'm guessing this is because the macOS machines have very little RAM and CodeQL is RAM hungry.
2. [CI Only] Initialize CodeQL
CodeQL Action v3 will be deprecated in December 2026. Please update all occurrences of the CodeQL Action in your workflow files to v4. For more information, see https://github.blog/changelog/2025-10-28-upcoming-deprecation-of-codeql-action-v3/
- Update the scripts SHA to that for 2025-12-03
- That broke several tests due to the change in Ninja version
- In order to fix that I updated the tests to ensure we were not triggering cross compilation unless we were actually intending to do that; for example we were selecting x64-osx even though arm64-osx is the 'normal' osx now.
- That change in expected triplet itself broke a lot of tests resulting in most of the edits here.
- Updating macOS and Ubuntu runners to 26/24.04 the stock GitHub Actions runners don't include a mono installation for the NuGet tests, so getting that on the boxes before running the e2e tests is done here.
In general the most impactful change is that we usually need to make a triplet with our expected changes on the fly rather than trying to make checked in test triplets. In particular detecting whether we are on arm64 is difficult because `CMAKE_HOST_SYSTEM_PROCESSOR` is not set before `project()` (as is normally the case in a triplet)
The 'upgrade' message asks users to rerun bootstrap-vcpkg. We used to do this all over the place but have been slowly doing it less often. Unfortunately, even the places that were reasonable, were mostly inconsistent about applying it.
In particular, emitting the upgrade message for things that require `git pull` is *incorrect*. Ever emitting the message in Visual Studio or one-liner deployments was always bogus.
(The reason for this is because I'm context-izing `vcpkg fetch` and there are a lot of problematic upgrade cases in there)
Audit results:
* strings.cpp:380: Wrong, parse failure is not a tool upgrade fix. (Note however the only callers where visualstudio.cpp which was questionably ok)
* strings.cpp:396: Ditto
* binaryparagraph.cpp:251: Both cases are about corrupted installation databases and both are wrong.
* binaryparagraph.cpp:261: Ditto
* commands.build.cpp:438: Probably correct, new vcpkg.exe may learn about new cpu architecture.
* commands.build.cpp:467: Probably correct, new vcpkg.exe may learn about new VS.
* commands.build.cpp:1045: Probably correct, new vcpkg may learn about new known architectures.
* commands.build.cpp:2147: Wrong, corrupted installation database.
* commands.edit.cpp:171: Wrong, nonexistent port won't be fixed by bootstrap.
* commands.format-manifest.cpp:59: This is just a bug in vcpkg and *probably* shouldn't be localized in the first place. It's a parse failure so it's wrong.
* commands.integrate.cpp:658: Plausible, new integrates may be learned by new vcpkg.exe.
* commands.package-info.cpp:47: Plausible, new vcpkg may have new package-info formats. But we don't emit the message for other unknown command line arguments so why is this one special?
* commands.remove.cpp:184: Wrong, upgrading vcpkg.exe won't make this not be manifest mode.
* commands.update.cpp:62: Ditto
* dependencies.cpp:299: Wrong, missing feature won't change by rebootstrap
* dependencies.cpp:860: Ditto
* registries.cpp:865: Wrong, missing git sha in the registry won't change by rebootstrap
* statusparagraph.cpp:86: Wrong, corrupted installation database.
* tools.cpp:854: Wrong, missing tool entry won't change by rebootstrap
* tools.cpp:1053: Plausible, new vcpkg.exe may learn new ways to find a tool from the system
* vcpkglib.cpp:201: Wrong, corrupted database.
* vcpkgpaths.cpp:86: Wrong, parse error.
* vcpkgpaths.cpp:195: Wrong, bogus git SHA.
Total: 6 correct/plausible, 16 wrong.
The bug is that https://github.com/microsoft/vcpkg-tool/blob/17ebfccd9b8d8c635407c4a01f06b46d69752100/include/vcpkg/base/parallel-algorithms.h#L78-L81 is missing a return statement, so both the foreground and background thread try to do the thing if and only if there is exactly 1 thing to restore from the binary cache
Before https://github.com/microsoft/vcpkg-tool/pull/1805 , clean_prepare_dir was not in the parallel region, so while we did launch a second useless 7z, it didn't tend to cause things to break since the duplicate copies wrote duplicate files. After that change though, one 7z tries to fill the directory while the other thread does clean_prepare_dir. At least one thinks a success happened, so subsequent parts of vcpkg assume that the CONTROL file inside is readable.
Example demonstrating that a cache restore needing exactly 1 restore fails while 2 or more succeeds is below.
I also changed ZipReadBinaryProvider to print even when not debugging and/or there is an expected success; that would have caught this issue or at least made it easier to explain.
```console
PS C:\Dev\vcpkg> C:\Dev\vcpkg-tool\out\build\Win-x64-Debug-WithArtifacts\vcpkg.exe install rapidcsv --binarysource "clear;x-azblob,https://vcpkgbinarycachewus.blob.core.windows.net/cache,REDACTED,read"
Computing installation plan...
The following packages will be built and installed:
rapidcsv:x64-windows@8.89
* vcpkg-cmake:x64-windows@2024-04-23
Additional packages (*) will be modified to complete this operation.
Detecting compiler hash for triplet x64-windows...
Compiler found: C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/cl.exe
warning: "C:\Dev\vcpkg-downloads\tools\7zip-25.01-windows\7z.exe" x "C:\Dev\vcpkg\buildtrees\vcpkg-cmake_791211895bfbb8dac9b79f35ee6d00ea0ee964e62694f558661e8f5a43016a64.zip" "-oC:\Dev\vcpkg\packages\vcpkg-cmake_x64-windows" -y failed with exit code 2
7-Zip 25.01 (x86) : Copyright (c) 1999-2025 Igor Pavlov : 2025-08-03
Scanning the drive for archives:
ERROR: The system cannot find the file specified.
C:\Dev\vcpkg\buildtrees\vcpkg-cmake_791211895bfbb8dac9b79f35ee6d00ea0ee964e62694f558661e8f5a43016a64.zip
System ERROR:
The system cannot find the file specified.
C:\Dev\vcpkg\buildtrees\vcpkg-cmake_791211895bfbb8dac9b79f35ee6d00ea0ee964e62694f558661e8f5a43016a64.zip: note: while extracting this archive
Restored 1 package(s) from HTTP servers in 1.3 s. Use --debug to see more details.
Installing 1/2 vcpkg-cmake:x64-windows@2024-04-23...
no such file or directory
PS C:\Dev\vcpkg> C:\Dev\vcpkg-tool\out\build\Win-x64-Debug-WithArtifacts\vcpkg.exe install zlib rapidcsv --binarysource "clear;x-azblob,REDACTED,read"
Computing installation plan...
The following packages will be built and installed:
rapidcsv:x64-windows@8.89
* vcpkg-cmake:x64-windows@2024-04-23
zlib:x64-windows@1.3.1
Additional packages (*) will be modified to complete this operation.
Detecting compiler hash for triplet x64-windows...
Compiler found: C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/cl.exe
Restored 2 package(s) from HTTP servers in 455 ms. Use --debug to see more details.
Installing 1/3 vcpkg-cmake:x64-windows@2024-04-23...
Elapsed time to handle vcpkg-cmake:x64-windows: 5.29 ms
vcpkg-cmake:x64-windows package ABI: 791211895bfbb8dac9b79f35ee6d00ea0ee964e62694f558661e8f5a43016a64
Installing 2/3 rapidcsv:x64-windows@8.89...
Building rapidcsv:x64-windows@8.89...
-- Using cached d99kris-rapidcsv-v8.89.tar.gz
-- Extracting source C:/Dev/vcpkg-downloads/d99kris-rapidcsv-v8.89.tar.gz
-- Using source at C:/Dev/vcpkg/buildtrees/rapidcsv/src/v8.89-cd345b3fd9.clean
-- Configuring x64-windows
-- Building x64-windows-dbg
-- Building x64-windows-rel
-- Installing: C:/Dev/vcpkg/packages/rapidcsv_x64-windows/share/rapidcsv/copyright
-- Performing post-build validation
Elapsed time to handle rapidcsv:x64-windows: 1.3 s
rapidcsv:x64-windows package ABI: a9ddd6a261ed7bb96b94a10d9f1be32ce4acbbd99bdb3d4daeb8d8264d45c637
Installing 3/3 zlib:x64-windows@1.3.1...
Elapsed time to handle zlib:x64-windows: 8.29 ms
zlib:x64-windows package ABI: 407af7bf6306e8a2c4f56671649adca653b9d1be17bc05ce5f1c66d29e74bb2f
Total install time: 1.3 s
Installed contents are licensed to you by owners. Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Packages installed in this vcpkg installation declare the following licenses:
BSD-3-Clause
MIT
Zlib
rapidcsv is header-only and can be used from CMake via:
find_path(RAPIDCSV_INCLUDE_DIRS "rapidcsv.h")
target_include_directories(main PRIVATE ${RAPIDCSV_INCLUDE_DIRS})
The package zlib is compatible with built-in CMake targets:
find_package(ZLIB REQUIRED)
target_link_libraries(main PRIVATE ZLIB::ZLIB)
All requested installations completed successfully in: 1.3 s
PS C:\Dev\vcpkg>
```
Prior to this we were dropping NuGet console output on the floor requiring folks to use --debug.
There is a behavior change here in that if the exit code was 0 before but the console output included "Authentication may require manual action." we would print a warning anyway, now the warning is only printed on failure.
Drive by: Audit for 'Nuget' -> 'NuGet' for correct branding.
* [Hotfix] Don't fail to enumerate file trees with broken symlink.
Resolves the 'fastdds' failures observed in https://github.com/microsoft/vcpkg/pull/47130
Note that the POSIX version of these functions already filter for ENOENT and ENOTDIR:
if (::stat(full.c_str(), &s) != 0)
{
if (errno == ENOENT || errno == ENOTDIR)
{
ec.clear();
}
* Add a Linux cmake preset that does not require node.js to be installed.
* [Hotfix] Don't fail to enumerate file trees with recursive symlinks
Fixes the wcslib:x64-android failures.
* [Hotfix] Harden filesystem ops in write_sbom.
Hopefully fixes:
error: open_for_read("/mnt/vcpkg-ci/p/salome-configuration_x64-linux/share/salome-configuration/copyright/modules.info"): Permission denied
