Here’s a quick rundown of where we stand. Please correct me if any of this is
inaccurate.
There are a few separate issues:
Path on disk of PAL folder: 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.
Namespace of PAL symbols: Sounds like everyone agrees there should just be a
top-level namespace PAL (and not WebCore::PAL).
#include style of PAL headers: Sounds like everyone agrees this should be the
<pal/Foo.h> style. There are two ways to achieve this:
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.
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.
Presence of an Xcode project: Sounds like this is possible and the best way
forward. Does this work back to the earliest OS we build on?
Static library or shared library: 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
An application to link to it and not to WebCore, such as a unit test suite, or
Some out-of-band layering enforcement, like a Python script.
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.
So, here are the items which need to be solved:
Do Xcode cross-project references work going back to the oldest Xcode we build
on?
Regarding issue #2 above, should I put source files in WebCore/pal or
WebCore/PAL/pal?
How do people feel about relying on a non-shipping application to enforce
laying in shipping code?
Also (note to self): I need to figure out the ForwardingHeaders story.
—Myles
> On Jan 14, 2017, at 10:47 AM, Konstantin Tokarev <[email protected]> wrote:
>
>
>
> 14.01.2017, 17:16, "Fujii Hironori" <[email protected]>:
>> On Sat, Jan 14, 2017 at 1:34 AM, Konstantin Tokarev <[email protected]>
>> wrote:
>>> 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.
>>>
>>> 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).
>>>
>>> [*] Assuming linker behavior similar to ELF linkers
>>
>> You can check unresolved symbols of the static library by creating a
>> unit test executable of PAL.
>
> Actually, it enough just to avoid adding WebCore to include directories of
> PAL, and code with layering violation won't compile.
>
>> _______________________________________________
>> webkit-dev mailing list
>> [email protected]
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> --
> Regards,
> Konstantin
> _______________________________________________
> webkit-dev mailing list
> [email protected]
> https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-dev
