Hey,

Was just having a conversation with Zan on IRC about how we can lessen
the pain of maintaining symbols filter/tracking files, and we came up
with a few ideas. There are two things that are a rather big pain in the
butt when it comes to symbols:

For continuous integration, it's very common to hit undefined symbols
when people add new test features.

For downstream packagers, symbol tracking can prove quite a work load,
having to track many C++ symbols which shouldn't really be part of the
ABI - and that often get different signatures for 32 and 64 bits builds.

For my more recent Debian packages I have decided to run an experiment:
I wrote my own symbols.filter file[0], and I patched the build system to
use it, and to not build tests, DumpRenderTree and GtkLauncher[1]. This
has improved life regarding maintenance of the symbols list[2] files
significantly[3].

It also has the small advantage of lowering the number of symbols in the
table, so it should give a small boost to symbol lookup times, but I
haven't measured or anything. I would like to add a way of doing this
upstream, so I can remove my patches and special handling.

On the other hand, it could be useful to relax symbol filtering for
developer and continuous-integration builds. I can think of the
following ways of achieving this:

     1. Add the 'maintainer mode' concept used by other auto*-based
        projects to our builds (I think we could add the concept to the
        cmake build as well), use it in build-webkit, and disable symbol
        filtering in this case
     2. Add a new configure switch to select symbol filtering level -
        none, normal (current situation), production (the downstream
        case); production would be the default for tarballs, normal
        would be the default for distcheck
     3. Use production symbol filtering by default and add a single
        configure switch to disable symbol filtering

I like 2 quite a bit because it can be represented neatly in our future
cmake build system, and because it gives us the best option for each use
case.

What do people think of this idea?

[0]: 
http://anonscm.debian.org/gitweb/?p=pkg-webkit/webkit.git;a=blob;f=debian/symbols.filter;h=a01a00c2ad85bb9ccad12d5a350c9b895f26c000;hb=HEAD
[1]: 
http://anonscm.debian.org/gitweb/?p=pkg-webkit/webkit.git;a=blob;f=debian/patches/01_do-not-build-testing-tools.patch;h=cd255af8536437571d15ec3a99a6e3ac3604aad1;hb=HEAD
[2]: 
http://anonscm.debian.org/gitweb/?p=pkg-webkit/webkit.git;a=blob;f=debian/libwebkitgtk-3.0-0.symbols;h=ad948a2c7a95dd1dc821b7d2c22b93bcef54f112;hb=HEAD
[3]: 
http://anonscm.debian.org/gitweb/?p=pkg-webkit/webkit.git;a=commitdiff;h=668cbe2b411e4bb9141cd5df8d10bb118cf2d404

Cheers,

-- 
Gustavo Noronha Silva <g...@gnome.org>
GNOME Project

_______________________________________________
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Reply via email to