Skip to content
This repository was archived by the owner on Dec 3, 2025. It is now read-only.

Conversation

@stuartmorgan-g
Copy link
Collaborator

Rather than have a C++ interface in the shared library, make the C++
code a client wrapper layer that plugins and embedders build with.

Ideally in the future more code will move out of this layer and behind
a C interface in the library, so that the wrapper is as thin as
possible, but this addresses the immediate issue of the shared library
not having a viable interface.

Fixes #230

Rather than have a C++ interface in the shared library, make the C++
code a client wrapper layer that plugins and embedders consume.

Ideally in the future more code will move out of this layer and behind
a C interface in the library, so that the wrapper is as thin as
possible, but this addresses the immediate issue of the shared library
not having a viable interface.
@stuartmorgan-g
Copy link
Collaborator Author

This is definitely not the most elegant handling of the client wrapper (e.g., it should ideally either become header-only, or at least have a simplified .cc structure that makes it obvious what files different clients should include), but this gets to the general structure, resolves the problem of requiring building the whole library from source (which in turn blocks migration to flutter/engine), and should hopefully unblock the switch to GN for Windows.

@stuartmorgan-g stuartmorgan-g merged commit b01f27f into google:master Feb 6, 2019
@stuartmorgan-g stuartmorgan-g deleted the client-wrapper branch February 6, 2019 17:13
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 9, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[linux/window] Fix exported API surface to be DLL/so-safe

2 participants