OS X implementation using a .dylib vs an app

[callum]

I'm trying to integrate CEF into an existing platform so my architectural choices are somewhat constrained.

The CEF based code has to go inside a plugin that is loaded at arbitrary times during the life on the main application.

I've gotten the Windows version (DLL) working and I'm happy to say it performs extremely well.

Next up is the OS X version and I'm struggling because (a) I know nothing about Xcode or OS X programming and (b) the constraints on app structure seem much more rigorous on OS X than Windows.

First thing I'd like to understand before I go too far down the rabbit hole is how the documented structure inside an application bundle can be applied to code hosted in a .dylib? Is that even possible?

[magreenblatt]

]First thing I'd like to understand before I go too far down the rabbit hole is how the documented structure inside an application bundle can be applied to code hosted in a .dylib? Is that even possible?

It is theoretically possible but you'll need to help Chromium/CEF find the correct paths to sub-resources (pak files, etc). Some of these can be customized via CefSettings and some will (currently) require changes to Chromium/CEF. See https://bitbucket.org/chromiumembedded/ ... ath-to-cef for an example of the types of problems you'll need to resolve.

[DanKegel]

I'm working around this currently by installing the framework to the dylib's install area.
The dylib is not a framework, just a plain old shared library.
Apps that want to use the dylib have to make four symlinks next to the app's binary, e.g.

# Temporary kludge until we patch chromium to search for these more sanely
for f in chrome-sandbox icudtl.dat natives_blob.bin snapshot_blob.bin
do
ln -sf $MY_DYLIB_PREFIX/bin/$f $f
done

I'll try out that patch, maybe it'll let me get rid of those four symlinks.
(The exact number of symlinks varies between branch, btw.)