[webkit-dev] WebCore/platform standalone library

[Michael Catanzaro]

On Fri, 2017-01-13 at 11:39 -0200, Gustavo Sverzut Barbieri wrote:
> On Thu, Jan 12, 2017 at 7:11 PM, Alex Christensen
> <achristensen at apple.com> wrote:
> > If PAL were a shared library in a CMake build, then it wouldn’t
> > build successfully if there were layering violations.  I think we
> > should do something like that to enforce good design, even if the
> > Mac Xcode projects treat it as a static library or even just a part
> > of WebCore.

Why does it matter if it's static or shared? Surely if PAL is build
before WebCore, and it's missing symbols at link time (because those
symbols actually exist in WebCore) and not linked to WebCore, then PAL
will fail to link regardless of whether it is a shared library or 
static library? Am I just downright wrong to assume this, or does it
work differently on Mac...?

(This is the biggest problem I see with the current plan. Regardless of
where the directory goes and what the namespacing looks like, I really
want to use the linker and not a python script to enforce layering.)

> Actually for development it would make lives much easier to keep it
> as shared library, reducing compile time and help to segment the
> symbols in a different space (linkers, gdb)
> 
> what if it becomes shared by default on Debug builds, static by
> default in Release? 

For GTK+, I'd really like it to be always a static lib as that's what
we need to ship and I wouldn't want to support multiple configurations.
Debug fission has solved our troubles with link time and gdb slowness.
But here it's possible for different ports to do different things. E.g.
some ports support building WebCore as a shared library, which is not
supported by GTK+.

Michael