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

[James Robinson]

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
https://bugs.webkit.org/show_bug.cgi?id=49192.

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:
https://docs.google.com/drawings/edit?id=11PDlM-Vu12TQy24tPpv2cvviBvuZzheKxhczf9JEXzo&authkey=CIbatNED&hl=en.
 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>