CEF Forum

We'd like to have direct access to the V8 api inside libcef.

Any guidance about having some of the source sets that go inside libcef.dll (specifically v8, v8_libbase, v8_libplatform, gin and maybe use external icu while we are at it) compiled and linked as shared libraries?

If the patch to accomplish that would be too hairy, would it be OK to compile and link another instance of V8 into our application? Any platform-specific differences that we should know about if we go this way?

Thanks!

In what process do you want to use V8 APIs, and why?

We are integrating our Qt app (that already uses CEF) with a v8-based scripting environment that's got nothing to do with the browser of web APIs. So it's going to be used in its own thread under the main process (that runs the Qt event loop), completely separate from CEF. We are just reluctant have a v8.dll next to a libcef.dll that has its own copy of the V8 engine, but we could do it if we thought we'd get away with it :/

I stumbled upon the following:

https://bitbucket.org/chromiumembedded/ ... -api-usage
viewtopic.php?f=7&t=67

but these are pretty old threads so I'm trying to understand how we'd do the same thing with a currently supported version of CEF.

it's going to be used in its own thread under the main process (that runs the Qt event loop), completely separate from CEF.

That should be fine from a design perspective, if not ideal from a security perspective. CEF/Chromium don't run V8 in the main process so there shouldn't be any runtime conflicts. You can look at if/how Electron builds Chromium with V8 as a separate dll, but it will likely be easiest for you to link your own separate lib/dll version of V8.

magreenblatt wrote:That should be fine from a design perspective, if not ideal from a security perspective.

Well, using Qt linked as shared libs on windows means you basically have to use dynamic CRT (/MD) which forces us to turn off the sandbox, unfortunately. we haven't yet found a way around this. Would switching to clang help in this regard?

magreenblatt wrote:CEF/Chromium don't run V8 in the main process so there shouldn't be any runtime conflicts.

Thanks, good to know.

I looked at at least exposing the v8 symbols in libcef.dll. I mean, I'm sure it'd possible to at least make them visible with enough work on the .gn files, but I noticed symbols like "std::Cr::unique_ptr" which seem come from the customized libcxx inside chrome. Wouldn't these be totally incompatible with regular C++ code that links with a standards-compilant runtime? Was this customized libcxx the reason why the C++ => C => C++ bridge, or classes like CefString became necessary?

If yes, then there really doesn't seem to be any practical way to talk to v8 directly inside the libcef.dll.