[webkit-dev] WebCore/platform standalone library

Myles C. Maxfield mmaxfield at apple.com
Wed Jan 11 10:30:50 PST 2017

> On Jan 10, 2017, at 11:08 PM, Carlos Garcia Campos <carlosgc at webkit.org> wrote:
>> El mar, 10-01-2017 a las 21:24 -0800, Myles C. Maxfield escribió:
>> After 18 months of no progress, Don Olmstead and I are getting the
>> band back together!
> Great news. 
>> We’ve uploaded a patch
>> to https://bugs.webkit.org/show_bug.cgi?id=143358 which incorporates
>> feedback from many different stakeholders (and as such, the direction
>> is a little different than where I was going with this in the
>> beginning).
>> 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.
> So, will it be possible to link to PAL but not the rest of WebCore?

Yes. This is the testing strategy. A goal is to be able to unit-test PAL without a layout test.

>> We opted for WebCore to include files using “#include <PAL/Foo.h>”
>> instead of just including Foo.h. Similarly, we are putting symbols
>> inside the PAL namespace, which is a child of the WebCore namespace.
>> Therefore, inside WebCore, you use PAL things by specifying
>> “PAL::Foo”.
> And WebCore::PAL::Foo when used outside WebCore namespace, right?


>> The first thing to move into PAL is the “crypto” subfolder, which is
>> a good candidate because it’s small, simple, yet also has platform-
>> dependent implementations.
>> We would love your feedback on this approach to help make the dream a
>> reality!
> I'm not sure I agree with the approach because I don't know the reasons
> to make it a target inside WebCore, could you elaborate more on that,
> please?

Build systems are already very complicated; we want fewer projects, not more of them. Also there's so complexity with ForwardingHeaders, which I'd like to avoid. We can achieve our objectives in the most simple way possible; no project is necessary. If, one day, we want PAL to be promoted to a project, we can do that then.

>> Thanks,
>> Myles and Don
>>> On Mar 22, 2015, at 4:40 PM, Gavin Barraclough <barraclough at apple.c
>>> om> wrote:
>>>> On Mar 22, 2015, at 4:35 AM, Maciej Stachowiak <mjs at apple.com>
>>>> wrote:
>>>> Web Abstraction Toolbox (it’s hard to tell the difference between
>>>> wat and WTF sometimes…)
>>> +1
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev

More information about the webkit-dev mailing list