[sdbusplus] add new port

[jbbjarnason]

• Changes comply with the maintainer guide
• The name of the port matches an existing name for this component on https://repology.org/ if possible, and/or is strongly associated with that component on search engines.
• Optional dependencies are resolved in exactly one way. For example, if the component is built with CMake, all find_package calls are REQUIRED, are satisfied by vcpkg.json's declared dependencies, or disabled with CMAKE_DISABLE_FIND_PACKAGE_Xxx
• The versioning scheme in vcpkg.json matches what upstream says.
• The license declaration in vcpkg.json matches what upstream says.
• The installed as the "copyright" file matches what upstream says.
• The source code of the component installed comes from an authoritative source.
• The generated "usage text" is accurate. See adding-usage for context.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is in the new port's versions file.
• Only one version is added to each modified port's versions file.

Added meson option async, to turn off internal impl of event loop, to use boost::asio only. It is both beneficial to reduce compile time of the port (if it is not needed don't compile it). Secondly, libc++ still does not implement internals of async.

Hacks to work with old version of meson where added.

[Neumann-A]

Updating meson is blocked by the tool RFC PR. Furthermore updating meson is no simple task since it requires changes to vcpkg_confgure_meson and how compiler flags are setup. (I mean I already did the work the problem is the tool blocker.)

[jbbjarnason]

Updating meson is blocked by the tool RFC PR. Furthermore updating meson is no simple task since it requires changes to vcpkg_confgure_meson and how compiler flags are setup. (I mean I already did the work the problem is the tool blocker.)

@Neumann-A , should I try to patch the current version instead?
Add support for cpp23 compiler flag.

Edit: Removed meson update and made small hacks to use the old version of meson.

[jbbjarnason]

Pipeline is failing https://dev.azure.com/vcpkg/public/_build/results?buildId=94519&view=logs&j=f79cfdd7-47a8-597f-8f57-dc3e21a8f2ad&t=da63cf11-1f12-503b-6d64-3b2fb713c172&l=2682

Should be resolved after merge of this PR: #33999

Edit: resolved

[jbbjarnason]

@FrankXie05 can you review this PR?

[dg0yt]

AFAICS that's already part of disable-boost-definitions.patch.

[jbbjarnason]

Can you please clarify what you mean?

disable-boost-definitions.patch is editing meson.build to prevent the code from building the library with its specified boost asio definitions, if it is built with those definitions and the consumer of the library does not specify those same definitions it will end in indexing nullptr errors within boost asio, really hard to track errors.

what the following part is resolving, is using meson version below v1.0 since vcpkg uses v0.6 which does not support the newly named option file meson.options:

# Hack to work with old meson version
file(COPY "${CMAKE_CURRENT_LIST_DIR}/meson_options.txt" DESTINATION "${SOURCE_PATH}")

[dg0yt]

I see now, one file is meson.options and the other one is meson.options.txt.
And we can't COPY_FILE the original file?

vcpkg uses v0.6

#28084 still suck 😞

[jbbjarnason]

Simplified with COPY_FILE as suggested. Thanks!

[jbbjarnason]

@FrankXie05 is there any progress with the reviewing of this PR?

[omarhogni]

Date-Version updated, @FrankXie05 @autoantwort are there any blockers for reviewing the PR. We are ready to make changes and work with you to get this merged.

[FrankXie05]

All features and usage have been tested successfully on x64-linux.

[dg0yt]

• Will the asio-only feature & patch remain to be maintained in vcpkg forever?
• Does the asio-only feature fulfil the "features are additive" requirement?

[omarhogni]

• Will the asio-only feature & patch remain to be maintained in vcpkg forever?

  • Does the asio-only feature fulfil the "features are additive" requirement?

After looking into this more closely this feature was added in order to compile the library under libc++ because stop_token is not implemented.

I have created a PR for upstream to try and solve that problem in the right place.
https://gerrit.openbmc.org/c/openbmc/sdbusplus/+/69768

Lets hold out and see how that pans out. I can also remove this feature and we can merge now. I would then just publish an update when/if the library compiles under libc++

[BillyONeal]

Giving upstream until March 29 to respond