[usbipdcpp] New port: A C++ library for creating usbip servers

[yunsmall]

Summary

This PR adds a new port for usbipdcpp, a C++ library for creating USB/IP servers.

Features

• USB/IP server implementation via libusb (works on all libusb-compatible platforms)
• Virtual HID device support (cross-platform, no libusb required)
• Hot-plug support for automatic device insertion/removal detection
• Asynchronous architecture using C++20 coroutines and asio
• Extensible design with abstract interfaces

Features available

• coroutine: Use C++20 coroutine-based implementation
• libusb: Build libusb-based server components for physical USB device forwarding

Usage

find_package(usbipdcpp CONFIG REQUIRED)
target_link_libraries(main PRIVATE usbipdcpp::usbipdcpp)

# With libusb support
find_package(usbipdcpp CONFIG REQUIRED COMPONENTS libusb)
target_link_libraries(main PRIVATE usbipdcpp::usbipdcpp usbipdcpp::libusb)

Checklist

- Changes comply with the https://github.com/microsoft/vcpkg-docs/blob/main/vcpkg/contributing/maintainer-guide.md.
- The packaged project shows strong association with the chosen port name.
  - The port name follows the 'GitHubOrg-GitHubRepo' form or equivalent Owner-Project form (github.com/yunsmall/usbipdcpp).
- Optional dependencies of the build are all controlled by the port (libusb is controlled by libusb feature).
- The versioning scheme in vcpkg.json matches what upstream says.
- The license declaration in vcpkg.json matches what upstream says (Apache 2.0).
- The installed as the "copyright" file matches what upstream says.
- The source code of the component installed comes from an authoritative source (GitHub release).
- The generated "usage text" is brief and accurate.
- 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.

[yunsmall]

@microsoft-github-policy-service agree

[vicroms]

Is this an alternative (see our docs)?

[yunsmall]

@vicroms Thank you for the review! I've made the following changes:

1. ✅ Used vcpkg_check_features instead of manual if/else
2. ✅ Removed unnecessary environment variable operations
3. ✅ Simplified vcpkg_cmake_config_fixup
4. ✅ Simplified the usage file

Regarding whether coroutine is an alternative: It's not a mutually exclusive alternative but an internal implementation detail (similar to bullet3's double/single precision feature), which is transparent to users.

Also added a busywait feature for lower latency mode.

[dg0yt]

FTR there is PR template for new ports, with a checklist.

[yunsmall]

@dg0yt Thank you for the review! I've applied all the suggested changes:

1. ✅ Updated to REF "v${VERSION}"
2. ✅ Fixed FEATURES indentation
3. ✅ Added quotes for CMake options
4. ✅ Updated usage file format

Regarding the two targets: usbipdcpp::libusb is an actual artifact (a static library usbipdcpp_libusb), not just a wrapper for
external libusb. It contains the libusb-based server implementation code. Users need to link both targets when using the libusb feature.

[dg0yt]

It contains the libusb-based server implementation code. Users need to link both targets when using the libusb feature.

So the usage file unconditionally recommends a target which is subject to feature control. Users invited to make mistakes.

Could you just drop the usage file? vcpkg tool's heuristical output will list the targets which are actually installed.

The file also lacks a newline at the end.

[yunsmall]

@dg0yt Done. I've removed the usage file and added MAYBE_UNUSED_VARIABLES for PKG_CONFIG_EXECUTABLE to fix the warning. Thank you for the review!

[dg0yt]

This still needs vcpkg x-add-version usbipdcpp, and adding the new versions/u-/usbipdcpp.json to git.

[BillyONeal]

• The port name follows the 'GitHubOrg-GitHubRepo' form or equivalent Owner-Project form (github.com/yunsmall/usbipdcpp).

This would mean the name should be yunsmall-usbipdcpp not just usbipdcpp

• 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.

If this had been done, your builds would be green.

[BillyONeal]

Is this an alternative? Is there any reason we should not just always do this?

[yunsmall]

busywait is a latency optimization feature that trades CPU efficiency for lower latency. It's not default behavior — only useful in specific low-latency scenarios. Most users don't need it.

[BillyONeal]

The way you describe it sounds like an alternative, not a feature. In particular, it sounds like a user could want to require that the feature is off which is not a thing features do. I think the port should pick one and this feature should not be added as a result.

[BillyONeal]

Should we have this feature or just always do this? Just because the upstream build system has a thing does not mean we should expose them as features.

[yunsmall]

The virtual device component adds build overhead and is only needed when creating software-emulated USB devices. Users who only forward physical devices via libusb don't need this. Upstream default is ON because examples depend on it, but for vcpkg users it should be opt-in.

[BillyONeal]

I'm not sure I agree; consider that package managers like apt et al. effectively only have one feature setting and people are fine with it. If it's not a substantial build time increase we may as well follow upstream's default. But in this case I'll defer to someone who clearly wants to actually use the library.

[BillyONeal]

"Request changes" over the "busywait" feature looking like an alternative and the version database being broken.

[BillyONeal]

The way you describe it sounds like an alternative, not a feature. In particular, it sounds like a user could want to require that the feature is off which is not a thing features do. I think the port should pick one and this feature should not be added as a result.

[BillyONeal]

I'm not sure I agree; consider that package managers like apt et al. effectively only have one feature setting and people are fine with it. If it's not a substantial build time increase we may as well follow upstream's default. But in this case I'll defer to someone who clearly wants to actually use the library.

[yunsmall]

@BillyONeal Thanks for the review. Here's what I've addressed:

1. busywait — Removed entirely. The busy-wait code path has been deleted upstream, so there's no corresponding CMake
   option anymore.
2. Version database — Fixed. Only one version entry (1.0.4) remains.
3. virtual-device — Kept as a feature. The virtual device code is a substantial separate component; it's not relevant for users who only want to forward physical USB devices, and
   embedded targets (ESP32) may want to skip it to reduce binary size. That said, I'm open to making it always-on if you feel strongly about it.

Let me know if there's anything else.