[webkit-dev] exporting symbols for building .so/.dll's

Martin Robinson mrobinson at webkit.org
Sat Mar 10 17:48:47 PST 2012

On Sat, Mar 10, 2012 at 4:34 PM, Alp Toker <alp at nuanti.com> wrote:

> If we follow this to the logical conclusion, no unification of granular
> export lists is realistic with the current WebKit porting layer. If the
> strategy were adapted to define exported functionality at class granularity,
> it might just be feasible, but again that is a contract that is begging to
> be broken, and besides, most toolchains lack export-by-class so it's a moot
> point.

While it seems that ports require a different set of exported macros,
there are certain subsets that all ports *do* need. One example of
this are symbols necessary for WebCoreInternals. I think this is a
great effort, because it improves test coverage for ports that don't
necessarily have the time to keep DumpRenderTree up to date. I watch a
lot of the WebCoreInternals bugs and I see that maintaining export
lists for different platforms, all which have their own unique way of
mangling symbols, is a huge burden.

> So the ultimate course of action is then to revert the macros and leave
> everyone to do what they think best in terms of export lists, then tying
> together those solutions where there's overlap.

I'm not sure I necessarily agree that the only answer to this problem
is to continue to force all ports to maintain their own export lists.
If the macros don't work out (and I'm not convinced that they cannot),
then we could simply teach the tools how to mangle symbols and make a
unified list of exports. Perhaps that's what you meant by "tying
together those solutions" though.


More information about the webkit-dev mailing list