[Webkit-unassigned] [Bug 199065] [GTK] Remove support for GTK2 plugins

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Jun 20 04:24:12 PDT 2019


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

--- Comment #8 from Adrian Perez <aperez at igalia.com> ---
(In reply to Carlos Garcia Campos from comment #3)
> Comment on attachment 372549 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=372549&action=review
> 
> >> Source/WebKit/PlatformGTK.cmake:-469
> >> -    PRIVATE
> > 
> > Is there any reason to remove the “PRIVATE” here? IIUC the GTK
> > Unix printing library would be still fine linked as such.
> 
> Michael told me this is useless in another patch.

As far as I understand the documentation, the following:

  target_link_libraries(a PUBLIC b PRIVATE c)

Will cause code that links against library “a” will be able to use
*also* symbols from “b”, but not symbols from “c” (unless it explicitly
links to “c” as well).

If the above is the case (I am not 100% sure, because the CMake
documentation is not particularly good), then it looks useful to
me, because it allows for containment of symbols from other libraries
used internally without exposing the transitively as part of the ABI
of the ABI of the “a” library. It also avoids overlinking… I suppose
this needs some support from the linker and that CMake can figure out
by itself how to put it to use.

So I wouldn't consider “PRIVATE” useless ;-)

(Of couse, “PRIVATE” should not be part of a list-variable, only
passed directly to “target_link_libraries”, so it's of course a
good thing that you removed it here.)

-- 
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/20190620/36ab65f9/attachment-0001.html>


More information about the webkit-unassigned mailing list