Skip to content

UniFFI C++ Bindgen Initial Integration - #249

Open
alan-george-lk wants to merge 10 commits into
mainfrom
alan/feature-uniffi-cpp
Open

alan-george-lk wants to merge 10 commits into
mainfrom
alan/feature-uniffi-cpp

Conversation

@alan-george-lk

@alan-george-lk alan-george-lk commented Sep 2, 2026

Copy link
Copy Markdown
Collaborator

Summary

This PR introduces the initial steps for uniffi integration. Depends on livekit/rust-sdks#1389 and release tag.

For this initial integration, a private header/adapter translation unit is added to test the UniFFI build version signature offered by the current livekit-ffi. This approach was taken to:

  1. Not expose this signature in the public header
  2. Not change building or linking behavior to expose the bindings directly to the unit test (better tests the build/link this way anyway)
  3. Allows these internal files to be deleted later once actual critical-path SDK features are moved over to UniFFI

Testing

Significant testing occurred locally across the bingden fork repository (testing C++ features), and in this repository through building/linking/etc. The new unit test is isolated and can be deleted later once other features move to UniFFI as mentioned above.

@alan-george-lk
alan-george-lk force-pushed the alan/feature-uniffi-cpp branch from 960aa52 to 46a4fab Compare September 9, 2026 22:22
@alan-george-lk alan-george-lk changed the title WIP: livekit-uniffi integration UniFFI C++ Bindging Integration Sep 10, 2026
@alan-george-lk alan-george-lk changed the title UniFFI C++ Bindging Integration UniFFI C++ Bindgen Integration Sep 14, 2026
@alan-george-lk alan-george-lk changed the title UniFFI C++ Bindgen Integration UniFFI C++ Bindgen Initial Integration Sep 14, 2026
@alan-george-lk
alan-george-lk marked this pull request as ready for review September 14, 2026 16:11
devin-ai-integration[bot]

This comment was marked as resolved.

Comment thread cmake/uniffi_cpp.cmake
Comment thread CMakeLists.txt
Comment thread CMakeLists.txt
namespace livekit {

std::optional<std::string> uniffiBindgenBuildVersion() {
auto version = livekit_ffi::build_version();

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is livekit_ffi::build_version() a rust impl thats getting called in cpp?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i.e. is this the "Secret Sauce"

@alan-george-lk alan-george-lk Sep 14, 2026

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is currently the only-available uniffi exported function in livekit-ffi: https://github.com/livekit/rust-sdks/blob/main/livekit-ffi/src/build_info.rs#L20-L23

This is the secret sauce in the sense that livekit_ffi is the uniffi generated namespace, and build_version is rust impl interfaced by the bindgen, so yes.

I tested all of this infra against livekit-uniffi but that is not actually targeted for critical path (per @1egoman), but allowed me to test more things:

https://github.com/livekit/rust-sdks/blob/main/livekit-uniffi/src/access_token.rs#L185-L189

and

https://github.com/livekit/rust-sdks/blob/main/livekit-uniffi/src/log_forward.rs#L27-L32

(removed from this branch for PR but part of history)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sweet thanks!

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't we expoe the ffi version via the public livekit header instead ?

livekit_ffi.hpp seems internal to me.

namespace livekit {

std::optional<std::string> uniffiBindgenBuildVersion() {
auto version = livekit_ffi::build_version();

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't we expoe the ffi version via the public livekit header instead ?

livekit_ffi.hpp seems internal to me.

///
/// @return The generated binding's build version, or no value if it is invalid
/// or the binding call fails.
LIVEKIT_INTERNAL_API std::optional<std::string> uniffiBindgenBuildVersion();

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here, the uniffi_bindgen_adapter.h seems internal to me, can we wrap it via some livekit public interface rather than directly expose it to public ?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Our build versions come from a compile-time generated file, with no actual linkage or implementation (just static values in a header): https://github.com/livekit/client-sdk-cpp/blob/main/build.h.in

I considered integrating this into the header, but that would significantly change how that file works and the build code around it. The goal of this integration was the infra around the bindgen fork, the Rust bindgen calls, and the CMake to wire it all up. This adapter is intentionally temporary and isn't actually useful, I planned on removing it later.

Hope this makes sense.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There might be a way to compile the bindgen code into a simple binary that CMake could call to get the same file statically, but that didn't feel useful

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

step back a bit, what is the purpose of exposing this uniffiBindgenBuildVersion() publicly ? is it for testing purpose ?

@xianshijing-lk xianshijing-lk left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I missed read the macro, it is LIVEKIT_INTERNAL_API

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants