[bde] Updated to 3.117.0

[adamncasey]

Fixes #18937

• 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
• Any fixed CI baseline entries are removed from that file.
• Any patches that are no longer applied are deleted from the port's directory.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is added to each modified port's versions file.

[BillyONeal]

I fixed version database for you :)

I removed the ci.baseline.txt skips for you so that bde is actually tested; this may result in failures because it was previously untested on Linux. If you don't think it should support android, & !android should get added to supports.

Thanks for your contribution to vcpkg!

[BillyONeal]

This looks like an 'alternative'; is it possible for downstream customers to be agnostic about this setting?

See https://learn.microsoft.com/en-us/vcpkg/contributing/maintainer-guide#do-not-use-features-to-implement-alternatives

[adamncasey]

It's a good question. I think the idea was to follow the abseil pattern here (maybe they're following something else which came before it).

There's definite trickiness around this setting and consuming the library - the header files of this library generally need to be built with a c++ standard identical to the static library linked against. I'm not sure what alternatives exist here

[BillyONeal]

It's a good question. I think the idea was to follow the abseil pattern here (maybe they're following something else which came before it).

Abseil does not follow such a pattern though, because they namespace all their polyfills. That is, customer code can be written always naming absl::stuff and it will work regardless of this setting.

There's definite trickiness around this setting and consuming the library - the header files of this library generally need to be built with a c++ standard identical to the static library linked against. I'm not sure what alternatives exist here

That's also something abseil doesn't do; there is a feature there but it bakes the 'polyfills or not' setting directly into the bits so that downstream C++ version need not agree.

In general we do not expect a given program to only ever be built with a consistent C++ version.

I think the correct think to do here is thus to turn on the setting and say "vcpkg's bde says you are using c++17+; if you want something else you must use overlays".

[adamncasey]

Thanks for the explanation - and time taken so far to consider this PR! 🙂. I might be misunderstanding your description since I haven't used abseil, but I think bde is in a similar situation wrt to polyfills - everything is namespaced.

In general we do not expect a given program to only ever be built with a consistent C++ version.
Makes sense, although as I'm sure you've realised - bde does expect that ~all usages of it's header files are linked against a version of the library which has been built with the same C++ standard version.

I think your suggestion is workable but could make it difficult to change the standard in future. I'll need to discuss internally to figure out what's feasible.

[BillyONeal]

See the exception we carved out specifically for what abseil was doing:

https://learn.microsoft.com/en-us/vcpkg/contributing/maintainer-guide#a-feature-may-replace-polyfills-with-aliases-provided-that-replacement-is-baked-into-the-installed-tree

In particular, the requirement to bake the feature answer into the resulting installed tree. bde[core] needs to use the polyfills even if downstream someone uses a C++17 compiler.

Unfortunately the C++ ecosystem writ large does not choose a consistent language version at any given time, so we require things indexed in our curated registry to deal with that situation.

[FrankXie05]

Please sign the CLA.
#31644 (comment)

[FrankXie05]

Note: I will be converting your PR to draft status. When you respond, please revert to "ready for review".
That way, I can be aware that you've responded since you can't modify the tags.

[adamncasey]

Closing this in favour of a PR opened from the bloomberg fork of vcpkg, with the intention of satisfying the CLA bot.