On Sat, Mar 10, 2012 at 4:34 PM, Alp Toker <a...@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. --Martin _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev