[Webkit-unassigned] [Bug 184379] [WPE] Decide how to handle libWPEWebInspectorResources.so

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Apr 10 17:03:25 PDT 2018


https://bugs.webkit.org/show_bug.cgi?id=184379

Adrian Perez <aperez at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aperez at igalia.com

--- Comment #1 from Adrian Perez <aperez at igalia.com> ---
(In reply to Michael Catanzaro from comment #0)
> libWPEWebInspectorResources.so is installed into libdir, which is probably
> OK, but:
> 
>  * It's not referenced in any pkg-config file, so it would be inappropriate
> for applications to link to it directly
>  * The only use inside WebKit is in RemoteInspectorUtils.cpp, where it is
> dlopened
> 
> If it's only ever dlopened, it should probably go into pkglibdir instead, to
> get it out of the linker search path. But this makes me question how the web
> inspector is intended to work by default. How can it work if it's not linked
> to its resources? Is only remote inspector supported? Why is this so
> different from WebKitGTK+?

Yup, pkglibdir is probably a good option. If it's going to be installed
alongside “WPEWebProcess” and friends, I would also make it possible to
override the path where it is searched for using “WEBKIT_EXEC_PATH”.

The inspector only ever needs reading resources when it's in use. While
not in use, it does not matter that the library is not loaded. This saves
around 2,5 MiB of RAM, and in very constrained environments it is possible
to skip shipping it — the inspector just won't work. I could argue that
WebKitGTK+ should follow suit and also ship a separate resources file.

What I don't understand is why using a shared object instead of a
“.gresource” file, and loading it with “g_resource_load()” followed
by a call to “g_resources_register()” — which uses “mmap()” under the
hood.

> One way or another, we need to ensure it is API-versioned, so if we do not
> move it to pkglibdir, we should append the API version to the library name.

Agreed. I would move it into pkglibdir.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180411/9e2e649f/attachment-0002.html>


More information about the webkit-unassigned mailing list