Skip to content

[vcpkg] Possibility to control the compiler hash for binary caching #16631

@klalumiere

Description

@klalumiere

Is your feature request related to a problem? Please describe.

This issue describes the context and motivation of a pull request I am about to open.

Binary caching uses hashes to make as likely as possible that, if cached binaries are used, they have compatible ABI. One of those hashes comes from the compiler. Actually, the whole compiler binary file is hashed:

file(SHA1 "${CMAKE_CXX_COMPILER}" CXX_HASH)

This of course contributes to the goal of making binary reused ABI-safe. I think this should remain the default vcpkg behavior.

That being said, within my organisation, this behavior removes much of the benefits of using (Nuget) binary caching, which we will probably need if we are to use vcpkg. We are ~20 C++ developers and each of us has a more or less different setup, which is also a bit different from our CI setup. If the binary caching works, it can take 8 minutes to a developer to build our main repository. If the binary caching doesn't work, it can take more than an hour. It means for instance that updating MSVC, could suddenly have a ~1h cost.

With our current setup, we use binaries compiled with different MSVC versions on Windows and clang versions on Linux. We are aware of the risk, but in more than 10 years, we've yet to identify a bug related to this risk. I think that they're might be other organisations with our use cases, so it would be nice to have an option to control how the compiler hash is computed.

Proposed solution
Instead of getting into discussion about what is safe to do and what is unsafe, I suggest that we use optional environment variables VCPKG_CXX_COMPILER_HASH_CMAKE_EXPRESSION and VCPKG_C_COMPILER_HASH_CMAKE_EXPRESSION. This would let users decide the risk they are comfortable to live with. If the variables are not defined, the default behavior remains.

Describe alternatives you've considered

All the solutions I considered maintain the current behavior as the default since it is the safest. They'd used environment variables to enable the more unsafe alternatives. For instance

  • Allowing the compiler hash to be fixed (VCPKG_SKIP_COMPILER_HASH), which would be unsafe, yet could be reasonable for some use cases.
  • Allowing the compiler hash to be just based on ${CMAKE_CXX_COMPILER_ID} or on ${CMAKE_CXX_COMPILER_ID}-${CMAKE_CXX_COMPILER_VERSION}.

This is because there were many alternatives that I thought about using a CMake expression. This way, users have control over the risk.

Additional context
I'm about to open a pull request implementing this (12-lines) feature

Metadata

Metadata

Assignees

Labels

category:vcpkg-featureThe issue is a new capability of the tool that doesn’t already exist and we haven’t committedrequires:tool-releaseAn issue that has been fixed in the microsoft/vcpkg-tool repo and is waiting for a release thereof

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions