<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 14, 2017, at 12:39 PM, Myles C. Maxfield <<a href="mailto:mmaxfield@apple.com" class="">mmaxfield@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Here’s a quick rundown of where we stand. Please correct me if any of this is inaccurate.<div class=""><br class=""></div><div class="">There are a few separate issues:</div><div class=""><ol class="MailOutline"><li class=""><b class="">Path on disk of PAL folder</b>: Sounds like everyone more-or-less agrees that this should belong in Source/, not in Source/WebCore/. However, I believe this is currently incompatible with Apple’s internal build infrastructure. If that’s true, then this issue is decided.</li></ol></div></div></div></blockquote><div><br class=""></div><div>While there are extra steps required, we can resolve this for PAL the same as was done for WTF. Or at least, I don't know of any issues that apply to PAL which did not apply to WTF at the time we moved it out. If you think you know of a reason and it's stuff we shouldn't talk about here, I'd be glad to discuss off-list.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><ol class="MailOutline" start="2"><li class=""><b class="">Namespace of PAL symbols</b>: Sounds like everyone agrees there should just be a top-level namespace PAL (and not WebCore::PAL).</li><li class=""><b class="">#include style of PAL headers</b>: Sounds like everyone agrees this should be the <pal/Foo.h> style. There are two ways to achieve this:</li><ol class=""><li class="">Add WebCore/ to the search path, and put PAL files in WebCore/pal/. This has a problem where it is easy to include other files inside WebCore but outside of PAL, since they are in the search path. This is the approach Don and I took in our patch, and solved this problem by using the Python script to check the #include lines.</li><li class="">Put PAL files in WebCore/PAL/pal/, and add WebCore/PAL/ to the search path. This has the same problem WTF has where there is a nested folder with the same name.</li></ol></ol></div></div></div></blockquote><div><br class=""></div><div>Don't we have these same two choices if the include style is <PAL/Foo.h>? However, this concern is moot if PAL becomes a top-level item under Source, or at least is planned to go there even if not immediately.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><ol class="MailOutline" start="4"><li class=""><b class="">Presence of an Xcode project</b>: Sounds like this is possible and the best way forward. Does this work back to the earliest OS we build on?</li><li class=""><b class="">Static library or shared library</b>: I was under the impression that using a shared library could potentially have performance problems, which would not occur with a static library. However, a shared library would enforce layering naturally, whereas a static library would need either</li><ol class=""><li class="">An application to link to it and not to WebCore, such as a unit test suite, or</li><li class="">Some out-of-band layering enforcement, like a Python script.</li></ol></ol><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>I’m a little hesitant to rely on a testing application to enforce layering in shipping code because some ports may choose not to build those tests.</div></div></div></div></blockquote><div><br class=""></div><div>WTF works fine as a static library that's layered under JavaScriptCore, and it doesn't have any kind of out-of-band enforcement tool. As far as I know, this works fine and has never led to a layering violation or other problem. The only enforcement is that WTF builds as a separate static library in a separate project, and doesn't include JavaScriptCore headers.</div><div><br class=""></div><div>Once again I would suggest that "do what WTF does" is likely to be a good solution.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">So, here are the items which need to be solved:</b></div><div class=""><ol class="MailOutline"><li class="">Do Xcode cross-project references work going back to the oldest Xcode we build on?</li><li class="">Regarding issue #2 above, should I put source files in WebCore/pal or WebCore/PAL/pal?</li></ol></div></div></div></blockquote><div><br class=""></div><div>I prefer the latter because: (a) it's more forward-looking if we eventually move PAL out to its own top level; and (b) it won't accidentally allow includes of other WebCore headers through an overly-broad include path.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><ol class="MailOutline" start="3"><li class="">How do people feel about relying on a non-shipping application to enforce laying in shipping code?</li></ol></div></div></div></blockquote><div><br class=""></div><div>It seems unnecessary. Being a separate module under source (or setting everything up as if it were that way already until we can move it) is sufficient for this kind of thing, as demonstrated by WTF.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div></div><div class=""><br class=""></div><div class="">Also (note to self): I need to figure out the ForwardingHeaders story.</div><div class=""><br class=""></div><div class="">—Myles</div><div class=""><br class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 14, 2017, at 10:47 AM, Konstantin Tokarev <<a href="mailto:annulen@yandex.ru" class="">annulen@yandex.ru</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><br class="">14.01.2017, 17:16, "Fujii Hironori" <<a href="mailto:fujii.hironori@gmail.com" class="">fujii.hironori@gmail.com</a>>:<br class=""><blockquote type="cite" class="">On Sat, Jan 14, 2017 at 1:34 AM, Konstantin Tokarev <<a href="mailto:annulen@yandex.ru" class="">annulen@yandex.ru</a>> wrote:<br class=""><blockquote type="cite" class=""> Static library is just an (indexed) archive of object files, symbol dependencies are not resolved when it is created. Instead this happens when static library is linked into shared library or executable.<br class=""><br class=""> If PAL is static and uses symbol from WebCore, link failure may happen only[*] if that symbol is not used anywhere in WebCore itself (provided that PAL stays after WebCore in linker command line and options like --start-group/--end-group are not used).<br class=""><br class=""> [*] Assuming linker behavior similar to ELF linkers<br class=""></blockquote><br class="">You can check unresolved symbols of the static library by creating a<br class="">unit test executable of PAL.<br class=""></blockquote><br class="">Actually, it enough just to avoid adding WebCore to include directories of PAL, and code with layering violation won't compile.<br class=""><br class=""><blockquote type="cite" class="">_______________________________________________<br class="">webkit-dev mailing list<br class=""><a href="mailto:webkit-dev@lists.webkit.org" class="">webkit-dev@lists.webkit.org</a><br class=""><a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" class="">https://lists.webkit.org/mailman/listinfo/webkit-dev</a><br class=""></blockquote><br class="">-- <br class="">Regards,<br class="">Konstantin<br class="">_______________________________________________<br class="">webkit-dev mailing list<br class=""><a href="mailto:webkit-dev@lists.webkit.org" class="">webkit-dev@lists.webkit.org</a><br class=""><a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" class="">https://lists.webkit.org/mailman/listinfo/webkit-dev</a><br class=""></div></div></blockquote></div><br class=""></div></div></div>_______________________________________________<br class="">webkit-dev mailing list<br class=""><a href="mailto:webkit-dev@lists.webkit.org" class="">webkit-dev@lists.webkit.org</a><br class="">https://lists.webkit.org/mailman/listinfo/webkit-dev<br class=""></div></blockquote></div><br class=""></body></html>