[webkit-dev] Moving WebCore to unified source builds and style changes.

[Ryosuke Niwa]

On Thu, Oct 12, 2017 at 2:53 PM, Keith Miller <keith_miller at apple.com>
wrote:

> Hello WebKittens,
>
> As discussed previously, I’m preparing to start migrating WebCore to
> unified-source builds. I was originally going to move over in one step but
> I have since realized that is going to be super hard to rebase fast enough.
> Instead I’ll move WebCore over incrementally. I have a full build of webkit
> working locally with both CMake and Xcode. The debug build time on my MBP
> went from ~25min to ~9min. There are still a bunch of files that don’t work
> with unified sources (mostly .mm files) that I will try to fix later.
>
> I had to make a bunch of source changes in order to get things to work
> (see: https://bugs.webkit.org/show_bug.cgi?id=178229):
>
> 1) Move all “using namespace <name>;” inside the WebCore namespace (they
> used to be in the global namespace) and change to "using
> WebCore::<type-name>;” in .mm files.
> 2) Move a bunch of the soft linking library/framework macros out of the
> .mm files since those caused name collision problems.
> 3) Fix minor other naming collisions.
>
> It seems like we are already moving away from 2 with PAL so I’m hoping
> that’s not contentious.
>
> The problem with 1 in a unified source world is generic names often
> collide with system header names. For example, WebCore has a Rect class and
> that collided with a system header type elsewhere. Thus, I propose that we
> change our style rules to forbid "using namespace” in the global scope and
> only allow them inside namespaces. We already have a stricter rule in
> headers so it doesn’t seem like a big change to apply this rule to .cpp
> files. Interestingly, it looks like JSC never followed the global namespace
> “using namespace" rule we currently have. Obviously, we’d need to update
> https://webkit.org/code-style-guidelines/, regardless of our final style
> choice.
>

Forbidding "using namespace" in the global scope seems fine. That's just a
bad practice anyway.

- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20171012/7fcabaac/attachment.html>