[vcpkg] RFC: Binarycaching

[ras0219-msft]

We are currently working on enabling caching and reuse of binaries to accelerate CI and per-project vcpkg instances; this our current working draft of the specification, ready for public commentary!

A limited form of this spec is already implemented and available in the tool today, via either --binarycaching or set VCPKG_FEATURE_FLAGS=binarycaching which will default to using $vcpkg_root/archives.

We would love feedback about whether this feature is useful to you or any additional scenarios you'd like to see covered!

• Backend #1: File-Based Archives
• Tracking Compilers
• Better control over source modifications
• Backend #2: NuGet (Azure DevOps Artifacts, GitHub Packages, etc)
• Configuration - Partially implemented
• Four-step flow

[Minimonium]

Note that stuff like the glibc version may differ on different distributions unrelated to the compiler.

[Minimonium]

To be sure, the hash is produced from the toolchain file as a plain file, without any structuring, correct? To reuse the same binaries you'd need to have exactly the same toolchain files?
For example, if you want to enable a different library feature - hashes won't clash, correct?

[cbezault]

Yup, the whole file is hashed. If there's any difference you won't end up with the same hash for the package.

[traversaro]

Thanks a lot for working on this. This is probably out of scope of the initial MVP, but have you consider the possibility of optionally download a binary with a different hash then what it would be build locally? I am thinking of cases like #10522 , in which a port does not compile under a given Visual Studio version for a Visual Studio regression, and then a binary compiled with a different version can be downloaded instead.

[ras0219-msft]

One core concept of our binarycaching approach is that this is only intended as an accelerant for what could be done locally; it's not intended to enable developers to (for example) not have a compiler toolchain at all.

In the case you mentioned, the workaround would be to have both toolchains available locally and use something like

if(PORT STREQUAL "ace")
  set(VCPKG_VISUAL_STUDIO_PATH "C:\\path\\to\\older\\vs")
endif()

This does have some problems (absolute paths to VS instances aren't portable), but it illustrates the overall direction where we would look for a solution.

[1] https:/Microsoft/vcpkg/blob/master/docs/users/triplets.md#vcpkg_visual_studio_path

[BillyONeal]

After seeing what the space consumption for our CI looks like, we also probably need to think about an eviction policy, like 'delete items from the cache which are not current hashes and have not been accessed in over $timeframe.

[bouffa]

Will be there a way to remove older versions of the packages from the binary archive? If I get it right, for now, if a port got updated (or a new CMake version etc...), a new binary archive will be built for it, but the older archives still remain in the archive directory, am I right?

[ras0219-msft]

In this initial implementation, we are not building any specific cache invalidation functionality into vcpkg. Depending on what backend you use, there might be an option on the provider's side to perform access-time based garbage collection (for example, Azure DevOps Artifacts has that for NuGet feeds).

We think that for most users, a once-in-a-while delete of ~/.vcpkg/archives will be sufficient; I could see us providing a courtesy function for that. In the future, we may investigate providing a more sophisticated system for the files-based backend based on file modified/access times.