[webkit-dev] Checking include paths in WebCore for bad dependencies

James Robinson jamesr at google.com
Mon Nov 8 11:47:39 PST 2010

Within WebCore there are a number of directories that can be thought of as
components with fairly well-defined dependencies.  For example,
WebCore/platform is intended to be a base component that the rest of WebCore
can depend on but that should not have any outward dependencies.  It's
possible that some day WebCore/dom will be a dependency of WebCore/html but
not the other way around.  However, in practice these dependencies get out
of hand pretty quickly.  There are a large number of files - both new and
old - in WebCore/platform that uses classes from WebCore/dom,
WebCore/rendering, etc.

I'd like to add a step to check-webkit-style that looks at the #includes in
a patch and generate a warning if the patch is introducing a bad dependency.
 For example, files under WebCore/platform/ should not depend on files under
WebCore/dom/ or WebCore/rendering/.  Historically the only enforcement for
these abstraction boundaries has been review, but this is a bit fragile
since it's not obvious when looking at #include "Foo.h" where Foo.h lives.
 Making bad includes show up when running check-webkit-style and in the
style-ews will make these bad includes more visible and hopefully help
people fix them.  There's an initial patch up at

Additionally, I'd like to use this tool to try to create and enforce some
more boundaries and one-way dependencies within WebCore.  Currently nearly
everything in WebCore is interdependent on everything else within WebCore
which makes it harder to understand the code and harder to patch it
correctly.  I made an attempt to diagram the dependencies by had to give up
pretty early on:
 We've also recently had a number of bugs where code in WebCore/rendering/
has called into editing or loader code that were not aware of the
requirements of rendering code.

Does this sound like a good set of goals?

- James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20101108/8b5a42bd/attachment.html>

More information about the webkit-dev mailing list