[webkit-dev] WebCore/platform standalone library

Michael Catanzaro mcatanzaro at igalia.com
Wed Jan 11 14:08:46 PST 2017


Really happy to see progress on this!

On Tue, 2017-01-10 at 21:24 -0800, Myles C. Maxfield wrote:
> First of all, this isn’t a new project; instead, it’s a new target
> inside the WebCore project. The target creates a static library which
> gets linked into WebCore, which means that the enforcement mechanism
> can’t be done by the linker. Instead, the layering will be enforced
> by a Python script, triggered as an extra build step, which checks
> the symbol names inside the .a file as well as #include directives in
> source code.

My preference remains to put PAL inside the toplevel Source/ directory
and make it a proper dependency of WebCore, because it seems far
superior to have the linker enforce layering. (A secondary concern is
that it will be nicer to say PAL::Foo rather than WebCore::PAL::Foo
when using PAL from the WebKit and WebKit2 layers.)

I appreciate that the decision to make it a target rather than a
dependency was driven by a desire to simplify the build system, and I
also appreciate that CMake and XCode are both complex beasts. But I
don't think this is the right approach. Consider that there is very
little material advantage to WebCore/PAL over the existing
WebCore/platform: we already have Tools/Scripts/check-for-platform-
layering-violations to check for platform layering violations, so the
only real advantage to adding PAL would be that PAL doesn't currently
have any such layering violations and so the layering enforcement
script could be run by the style checker. If that were the only goal,
then it would be simpler to keep WebCore/platform and just fix the
layering violations than to slowly move everything to a new directory.
I'd much rather let the linker handle layering enforcement; then there
is real value to splitting out PAL.

Michael


More information about the webkit-dev mailing list