I imagine it went down like this at the #MicrosoftAzure design meeting:
> Microsoft engineer: We should store the MD5 of the content in the blob storage database.
> Senior Microsoft engineer: Let's use #dotnet (!), and interpret the hexadecimal MD5 (with a newline!) as binary, and then base64 encode it!
They might have saved a couple of bytes... #dotnet ...👏 ...😬
#MicrosoftLogic #ShamelessTechShaming #LegacyTech #LegacyCode #LegacyCodeProblems
Puzzled that there is a "Troubleshooting ABI mismatch" guide, but seemingly no concise list of factors in play.
https://learn.microsoft.com/en-us/vcpkg/users/binarycaching-troubleshooting#abi-mismatch
#MicrosoftLogic #MicrosoftDocumentation
#CorporateTech
#WhyVcpkgWhy #LegacyCodeProblems
Obvious sources of a #vcpkg package ABI hash:
✅ vcpkg tool/binary
✅ The microsoft/vcpkg repo root in use (due to the `scripts` directory containing CMake definitions etc.)
✅ Compiler(s) (version) (something like a hash of the compiler binary similar to the approach used by ccache, and sccache)
❓ vcpkg triplet. Is the content of the vcpkg triplet file in play or is it just the triplet name?
❓ vcpkg overlay triplets
✅ portfile and/or hash of the port directory
I still don't get the algorithm that determines whether #vcpkg re-uses a cached binary or re-builds from source.
I get that it is determined by the ABI checksum/hash that vcpkg calculates, I just utterly do not understand the set of factors that might influence the ABI hash calculation.
@horenmar It certainly features a "unique" design! 😊
> vcpkg has a unique way of handling package versions
https://learn.microsoft.com/en-us/vcpkg/get_started/overview#why-vcpkg
