On Fri, Jan 11, 2019 at 3:43 AM, Tomas Popela <tpop...@redhat.com>
wrote:
* In CMAKE files the ENABLE_API_TESTS is guarded by the
DEVELOPER_MODE
* 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
DEVELOPER_MODE ifdefs.
* 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
PerProcess<anything>).
Michael
_______________________________________________
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk
