Re: [webkit-dev] WebCore/platform standalone library

[Alex Christensen]

Windows must also stay a static library.  I can volunteer the 
currently-completely-experimental-anyways Mac CMake build to have PAL as a 
shared library.  It would be nice if people had more of a reason to keep it 
working.
> On Jan 18, 2017, at 1:23 PM, Michael Catanzaro  wrote:
> 
> On Wed, 2017-01-18 at 12:17 -0800, Myles C. Maxfield wrote:
>> Static (At least for the Xcode projects. I imagine the cmake-based
>> projects could do whatever they want here).
> 
> For GTK+ we really want static as well, we do not want a new shared
> library. So no difference here.
> 
> Michael
> ___
> 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

Re: [webkit-dev] WebCore/platform standalone library

[Michael Catanzaro]

On Wed, 2017-01-18 at 12:17 -0800, Myles C. Maxfield wrote:
> Static (At least for the Xcode projects. I imagine the cmake-based
> projects could do whatever they want here).

For GTK+ we really want static as well, we do not want a new shared
library. So no difference here.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Myles C. Maxfield]

Alright - I’ve had a long and involved conversation with people who know things 
about Apple’s internal build infrastructure. The result of this conversation is:

1. Currently, the build infrastructure is configured in such a way as to not be 
compatible with a new folder in the top-level Source directory. Therefore, PAL 
must live inside a subdirectory of WebCore for now. We have plans to 
reconfigure the build infrastructure to relax this constraint, but it is 
difficult enough that it won’t be done soon. Once the constraint is relaxed, we 
can move PAL to a top-level directory inside Source.

2. Making a new Xcode project for PAL is the most sensible way forward.

I think this unblocks us. I’ll answer all the open questions inline below.

—Myles

> On Jan 14, 2017, at 12:39 PM, Myles C. Maxfield  wrote:
> 
> 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.

Source/WebCore/PAL

> Namespace of PAL symbols: Sounds like everyone agrees there should just be a 
> top-level namespace PAL (and not WebCore::PAL).

PAL, not WebCore::PAL

> #include style of PAL headers: Sounds like everyone agrees this should be the 
>  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.

The second option

> 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?

Yes

> 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.

Static (At least for the Xcode projects. I imagine the cmake-based projects 
could do whatever they want here).

> 
> 
> 
> 
> 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 > > wrote:
>> 
>> 
>> 
>> 14.01.2017, 17:16, "Fujii Hironori" > >:
>>> On Sat, Jan 14, 2017 at 1:34 AM, Konstantin Tokarev >> > 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
>>> webkit-dev@lists.webkit.org 
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> -- 
>> Regards,
>> Konstantin
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org 
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webki