[boost] update to 1.92.0

[miyan (miyanyan)]

• Changes comply with the maintainer guide.
• SHA512s are updated for each updated download.
• The "supports" clause reflects platforms that may be fixed by this new version, or no changes were necessary.
• Any fixed CI baseline and CI feature baseline entries are removed from that file, or no entries needed to be changed.
• All patch files in the port are applied and succeed.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Exactly one version is added in each modified versions file.

[Billy O'Neal (BillyONeal)]

Drafted due to build failures. miyanyan#4 may fix

[Billy O'Neal (BillyONeal)]

miyan (@miyanyan) Curious as to your thoughts. We just turned on this CRLF check. Do you prefer it showing up as it does here or do you just find it frustrating and wish I had submitted a PR about it instead?

Thanks!

[miyan (miyanyan)]

miyan (miyan (@miyanyan)) Curious as to your thoughts. We just turned on this CRLF check. Do you prefer it showing up as it does here or do you just find it frustrating and wish I had submitted a PR about it instead?

Thanks!

I'm ok to turn on CRLF check, what about adding git hook tools like pre-commit for the existing line-ending check?

[miyan (miyanyan)]

Billy O'Neal (@BillyONeal) The Boost update also changes the contents of vcpkg-boost, while its date-based version remains 2025-03-29. My understanding is that this should be represented by adding "port-version": 1 rather than changing the date version. Is that the expected approach for this Boost update?

[Billy O'Neal (BillyONeal)]

My understanding is that this should be represented by adding "port-version": 1 rather than changing the date version.

It's helper scripts for us and we're bumping them so I would bump the date to today

[Billy O'Neal (BillyONeal)]

I'm ok to turn on CRLF check, what about adding git hook tools like pre-commit for the existing line-ending check?

1. I'm not confident in getting something that could consistently go into a commit hook; the current way we are doing this assumes a bunch of *nix tools.
2. Speaking personally I'm not a fan of pre-commit things because I often make many intentionally garbage quality commits to have checkpoints to go back to, or because it's 7PM and I'm going home, or something like that. I only expect to clean that stuff up when showing to other people, which is the pull request process. But I acknowledge that this is my very personal view on the subject

[Billy O'Neal (BillyONeal)]

Thanks for the update!