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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev