[webkit-gtk] Make unit tests buildable from tarballs

Michael Catanzaro mcatanzaro at igalia.com
Tue Jan 15 14:08:31 PST 2019

On Fri, Jan 11, 2019 at 3:43 AM, Tomas Popela <tpopela at redhat.com> 
>  * In CMAKE files the ENABLE_API_TESTS is guarded by the 
>  * The tests itself depends on the WebKit C API, that is not exported 
> in our shared library (it's filtered out by the 
> webkitglib-symbols.map). The list of what symbols are needed is on 
> the end of this mail.
>  * Even if we add all the required C APIs to the map, then the 
> compilation will the tests use private functions that are again not 
> exported - e.g. the WebProcessTest uses 
> webkitWebExtensionSetGarbageCollectOnPageDestroy() from 
> Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitWebExtensionPrivate.h
>  * To be able to run the tests from the builddir we would have to 
> move functions or their parts like getExecutablePath(), 
> findWebKitProcess() in 
> Source/WebKit/Shared/glib/ProcessExecutablePathGLib.cpp and 
> injectedBundleDirectory() in 
> Source/WebKit/UIProcess/API/glib/WebKitWebContext.cpp outside of the 
>  * It "probably" needs files that are not included in the tarball

I don't think we need a new libwebkit2gtktest library if we build 
separate static libs. Then the API tests could link against the static 
libs, and you'd have access to everything?

We could also internally build everything as static libs, and add 
shared libs linked to those at the end of the build?

Linking is hard. :( Our current status quo has a serious problem that 
all internal WTF and JSC and bmalloc symbols are public anyway, via 
libjavascriptcoregtk, where we can't hide internal symbols because it 
would break C++ templates used as global variables (like 


More information about the webkit-gtk mailing list