> On Jan 11, 2017, at 5:43 PM, Maciej Stachowiak <m...@apple.com> wrote: > > > To be clear, I think PAL is a great move. Details like the namespace, > placement of the code, and how includes look are all things that can be > changed after the fact. > > That said, I think we need to ultimately consider our porting layer to be the > combination of PAL and WTF, so it is good for the two to be consistent. I > hope revisions along these lines can be considered in due course.
Indeed, some considerations relating to the Apple production build process led me to suggest that we avoid adding another subdirectory under Source. I believe that at some point in the future, those considerations will no longer hold. Even before then, while still keeping the PAL source code inside Source/WebCore, we should be able to take advantage of Xcode’s support for cross-project references and create a separate Xcode project for PAL (in a subdirectory of Source/WebCore), which will allow for better—or at least simpler—enforcement of the separation (and for an easier move to a top-level Source subdirectory in the future). > > Regards, > Maciej > >> On Jan 11, 2017, at 3:30 PM, Olmstead, Don <don.olmst...@sony.com >> <mailto:don.olmst...@sony.com>> wrote: >> >> I was the one who did the WebCore::PAL namespace so I wanted to chime in on >> why I went that route. We at Sony are newcomers to pushing to trunk so my >> explanation might be entirely too idealistic but here goes. >> >> I had thought of PAL as a library that is internal to WebCore that provides >> a clear porting layer. I would not expect anyone outside of WebCore to be >> linking to it. Because of that it was living inside Source/WebCore, and >> since it was setup that way having an internal namespace of WebCore::PAL >> made sense conceptually. Also in the future if PAL was successful I could >> see a WebKit2 equivalent. >> >> Whatever the consensus is we’re looking forward to working on getting the >> PAL layer up and running. We’re working on rebooting our port so we’re in a >> good position to help build it out and do any refactoring to help create a >> clear layering. Having a clear porting layer, especially one with tests, is >> something we’re hoping will be beneficial to all the ports. >> >> From: webkit-dev-boun...@lists.webkit.org >> <mailto:webkit-dev-boun...@lists.webkit.org> >> [mailto:webkit-dev-boun...@lists.webkit.org >> <mailto:webkit-dev-boun...@lists.webkit.org>] On Behalf Of Maciej Stachowiak >> Sent: Wednesday, January 11, 2017 2:05 PM >> To: Antti Koivisto <koivi...@iki.fi <mailto:koivi...@iki.fi>> >> Cc: Webkit Development List <webkit-dev@lists.webkit.org >> <mailto:webkit-dev@lists.webkit.org>>; mrobin...@igalia.com >> <mailto:mrobin...@igalia.com> >> Subject: Re: [webkit-dev] WebCore/platform standalone library >> >> >> These both sound right to me. >> >> More generally, I would expect that over time, PAL would likely become a >> peer project to WebCore instead of being inside it, much the same way WTF >> started inside JavaScriptCore and eventually moved outside it in the source >> tree. In the WTF case, it always had a separate top-level namespace. >> >> On Jan 11, 2017, at 12:27 PM, Antti Koivisto <koivi...@iki.fi >> <mailto:koivi...@iki.fi>> wrote: >> >> Why is the PAL namespace inside the WebCore namespace? Couldn't it just be a >> top-level namespace (even if it currently happens to live in the WebCore >> project)? >> >> #include <pal/Foo.h> would be more consistent with existing headers than >> <PAL/Foo.h>. >> >> >> antti >> >> On Wed, Jan 11, 2017 at 7:24 AM, Myles C. Maxfield <mmaxfi...@apple.com >> <mailto:mmaxfi...@apple.com>> wrote: >> After 18 months of no progress, Don Olmstead and I are getting the band back >> together! >> >> We’ve uploaded a patch to https://bugs.webkit.org/show_bug.cgi?id=143358 >> <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. >> >> 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”. >> >> 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! >> >> Thanks, >> Myles and Don >> >> On Mar 22, 2015, at 4:40 PM, Gavin Barraclough <barraclo...@apple.com >> <mailto:barraclo...@apple.com>> wrote: >> >> On Mar 22, 2015, at 4:35 AM, Maciej Stachowiak <m...@apple.com >> <mailto:m...@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@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >> https://lists.webkit.org/mailman/listinfo/webkit-dev >> <https://lists.webkit.org/mailman/listinfo/webkit-dev> >> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >> https://lists.webkit.org/mailman/listinfo/webkit-dev >> <https://lists.webkit.org/mailman/listinfo/webkit-dev> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >> https://lists.webkit.org/mailman/listinfo/webkit-dev >> <https://lists.webkit.org/mailman/listinfo/webkit-dev> > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
