-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generate full-coverage safe bindings from the bindgen C API output #9
base: main
Are you sure you want to change the base?
Conversation
See also chromiumembedded/cef#3836 for progress on making CEF itself redistributable. |
@wusyong BTW, what do you think of moving this to the https://github.com/tauri-apps org for ongoing development? Ideally, that would include publishing/ownership on crates.io as well. |
@wravery Thanks for the PR! Bindgen was on my list for this project back in the day. Unfortunately, I've been laid off from the company that sponsored my work in Tauri. I haven't followed its development for a while. That said, I'll still try to review it next week if I have time. Have you tried running it on Linux? I mean Wayland more specifically. One of the reasons I tried to explore this port is that webkitgtk is underperforming a lot. However, last time I checked cef's wayland port isn't great either. |
Oh, I'm sorry to hear about the layoff! I saw that you were still active in other projects like Servo and figured you'd just shifted focus. You are missed in the Tauri project. To your question about Wayland, I have been testing with the The thing that prompted me to get involved was I started hearing about cases where browser compatibility on Linux was blocking adoption. In other words, performance wasn't the primary concern, browser compatibility/consistency was. From the Tauri perspective, it would be great to have an option of switching to CEF as necessary (e.g., when migrating from Electron's Chromium front end), even if we stick with another rendering engine by default. |
Webkit has a lot of problems. For example in Modrinth App (which uses tauri) there are a lot of performance issues modrinth/code#3057, random freezes modrinth/code#1127, modrinth/code#1216 etc. I'm using Gentoo Linux with Gnome and CEF seems way more stable than webkit. I tested random websites, browser benchmarks and this solution works perfectly fine. |
@wravery sorry for bothering you here, |
Hi @csmoe 👋🏼, I'd be happy to work with you on that. Trying out the I'd still like to try to upstream those changes and mine to this project, if only so that we can keep the crate name |
I got this idea from noticing that CEF already relies on code generators to translate the internal C++ API to a C API in the DLL/cdylib exports, then generates C to C++ bindings for consumption there. The
bindgen
tool already does a pretty good job with the C API, but it's all unsafe and much harder to use without the wrapper types you were already working on. The problem with the wrapper types though is that they need to be hand-coded and kept in sync with new versions of CEF.To fix that, I implemented a code generator in the unpublished
update-bindings
crate that parses the currentbindgen
output in/sys/src/bindings.rs
with thesyn
crate and then outputs safe wrappers for the whole C API with thequote
crate, much like a proc-macro would.The main source for
update-bindings
is in/update-bindings/src/parse_tree.rs
, and the output is in/cef/src/bindings.rs
. I was able to delete most of the wrapper type modules aside from some custom implementations in therc
andstrings
modules.I restructured the cargo workspace to put each crate in a sub-directory, so the main
cef
crate is no longer in the root directory, it's in/cef/...
. The easiest way to compare the before and after API is to look at the original/examples/demo.rs
vs. thedemo
in its new location,/cef/examples/demo.rs
.