[linux/window] Fix exported API surface to be DLL/so-safe #230
Comments
|
Not having a Windows development background, I was not aware of the severe limitations on what can safely be used in a DLL interface. (Having seen this export pattern in Chromium, I didn't expect issues, but Chromium's build doesn't create DLLs for distribution). It look like the Windows API surface will need to be completely rethought. |
|
Although since most of the current approach is templated, and thus entirely in headers, it may be salvageable with some adjustments. I'll need to do more research. |
|
I have gotten rid of the warnings by removing the export from the class and adding it to each method and member individually but leaving out the private members (IIRC shouldn't need exporting). I still want to test this further before creating a PR with some simple plugins and embedders to see if this causes any issues. Linux and macOS still pass testing so I think everything will be okay. |
|
The issue isn't so much the warnings as the problem of the STL not having a stable ABI, making the use of the STL in DLL interfaces untenable. (Which I became aware of while reading up on the warning.) Things work right now because everything is being compiled at once by the same compiler, with the same settings. That's not something that can be guaranteed in a binary distribution model. |
stuartmorgan-g
changed the title
|
Retitling for the expanded scope. Currently my thinking is that I'll pare the actual library interface down to a small number of abstract interfaces with no STL use. The bulk of the code will remain template headers, which won't actually be exported from the DLL, just available for clients to use, so that in practice the client code API surface will look much the same, even though the DLL API is pared down. I'll likely need to add one or two utility headers to wrap the raw memory management that the API will need to use with smart pointers, so that client code doesn't have that foot-gun to deal with. I haven't implemented this yet, so it may end up being more extensive than I'm currently hoping, but given how much is currently pure-header I'm hopeful that it won't be a huge change. |
|
For my non glfw port, I have been considering using WinRT to expose a richer API is that interesting?
…Sent from my iPhone
On Jan 14, 2019, at 8:58 AM, stuartmorgan <[email protected]<mailto:[email protected]>> wrote:
Retitling for the expanded scope. Currently my thinking is that I'll pare the actual library interface down to a small number of abstract interfaces with no STL use. The bulk of the code will remain template headers, which won't actually be exported from the DLL, just available for clients to use, so that in practice the client code API surface will look much the same, even though the DLL API is pared down. I'll likely need to add one or two utility headers to wrap the raw memory management that the API will need to use with smart pointers, so that client code doesn't have that foot-gun to deal with.
I haven't implemented this yet, so it may end up being more extensive than I'm currently hoping, but given how much is currently pure-header I'm hopeful that it won't be a huge change.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fflutter-desktop-embedding%2Fissues%2F230%23issuecomment-454079220&data=02%7C01%7C%7C9cadb6f6bee0451acc8b08d67a41887c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636830819209046306&sdata=HhYeLFfQmfObRKJkDG%2FSzOv4AthZbQUXD5z8EEKNDLI%3D&reserved=0>, or mute the thread<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABE3OlIf3wlFvHK76S4-y8H41JvJJHTdks5vDLc-gaJpZM4Z8fUc&data=02%7C01%7C%7C9cadb6f6bee0451acc8b08d67a41887c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636830819209046306&sdata=nubfD%2B3iavmbqaWIT5hVUPj5MWZJFFOWlAcmlqmtSSM%3D&reserved=0>.
|
|
From a cursory look at how APIs work it's not clear to me what the compat implications are; potentially? If it's using something with strong binary compat as the actual boundary, and then transparently layering C++ over that for the caller, that could certainly be useful for the Windows-specific APIs (that's what I'm hoping do to more or less do with the plugin APIs, only manually). |
Creates an initial C++ object as the primary intaction point for the embedder calls. This provides a simpler API surface than embedder.h, and folds in some common code (e.g., error logging). This also serves to insulate clients from the embedder.h API layer, so that future incremental changes done for google#230 will cause less churn for embedders.
Creates a simple C++ object as the primary interaction point for the embedder calls. This provides a simpler API surface than embedder.h, and folds in some common code (e.g., error logging). This also serves to insulate clients from the embedder.h API layer, so that future incremental changes done for #230 will cause less churn for embedders.
Rather than exposing the GLFWwindow that is used, treat it as an implementation detail and use an opaque pointer specific to this library as the context object instead. In practice the use of GLFW can't be entirely internal since the use of GLFW in the library prevents its use by the embedder, but the details of how it is used should not be exposed. This also gives greater control over the API surface, as part of working toward a stable ABI (google#230). This does mean that the embedder cannot manipulate the GLFW window directly, but rather than trust that doing so would be safe across DLL boundaries, any functionality need by the simple embedder use cases this library enables should be exposed via wrappers.
Rather than exposing the GLFWwindow that is used, treat it as an implementation detail and use an opaque pointer specific to this library as the context object instead. In practice the use of GLFW can't be entirely internal since the use of GLFW in the library prevents its use by the embedder, but the details of how it is used should not be exposed. This also gives greater control over the API surface, as part of working toward a stable ABI (#230). This does mean that the embedder cannot manipulate the GLFW window directly, but rather than trust that doing so would be safe across DLL boundaries, any functionality need by the simple embedder use cases this library enables should be exposed via wrappers.
Eliminates PluginRegistrar and BinaryMessenger from the embedder.h API surface, moving them up to the FlutterWindowController level. In their place, adds new low-level messaging APIs, which are based closely on the Flutter engine embedder APIs (including an equivalent message struct), in some cases wrapping them directly. Unlike the engine APIs, they allow per-channel callbacks, so individual plugins can use the API. Since PluginHandler is no longer the source of truth for callback registration, only an adaptor, it's now fine to have multiple instances of them, all passing through to the underlying C API. Part of google#230
Eliminates PluginRegistrar and BinaryMessenger from the embedder.h API surface, moving them up to the FlutterWindowController level. In their place, adds new low-level messaging APIs, which are based closely on the Flutter engine embedder APIs (including an equivalent message struct), in some cases wrapping them directly. Unlike the engine APIs, they allow per-channel callbacks, so individual plugins can use the API. Since PluginHandler is no longer the source of truth for callback registration, only an adaptor, it's now fine to have multiple instances of them, all passing through to the underlying C API. Part of #230
Remove remaining C++ from embedder.h, and add extern C. Part of google#230
Remove remaining C++ from embedder.h, and add extern C. Since the namespace is removed, use a standard prefix for all function names. Part of #230
VS builds now have a large number of export warnings since #216 landed.
Log:
The text was updated successfully, but these errors were encountered: