Bug 41398 – Unfork Chromium's FontPlatformDataMac.mm

• Component: WebKit Misc.
• Status: RESOLVED FIXED

[Jeremy Moskovich]

https://bugs.webkit.org/show_bug.cgi?id=41148 forks FontPlatformDataMac.mm for the Chromium port to enable cross-process font loading.

This bug tracks unforking the file.

[Jeremy Moskovich]

Created attachment 65262 [details]
platform/graphics/mac -> platform/graphics/cocoa

As a first step, per Joseph's comment at https://lists.webkit.org/pipermail/webkit-dev/2010-July/013409.html I've attached a patch that moves FontPlatformData.h and FontPlatformDataMac.mm to platform/graphics/cocoa .  The next step will be merging the actual code changes.

[Eric Seidel (no email)]

Attachment 65262 [details] did not build on mac:
Build output: http://queues.webkit.org/results/3705586

[Jeremy Moskovich]

(in response to Mac EWS: builds fine for me locally, I'll double check before landing),

[Eric Seidel (no email)]

The EWS is saying:

In file included from /Users/eseidel/Projects/MacEWS/WebCore/platform/graphics/FontFallbackList.h:25,
                 from /Users/eseidel/Projects/MacEWS/WebCore/platform/graphics/Font.h:30,
                 from /Users/eseidel/Projects/MacEWS/WebCore/rendering/style/RenderStyle.h:48,
                 from /Users/eseidel/Projects/MacEWS/WebCore/css/CSSStyleSelector.h:28,
                 from /Users/eseidel/Projects/MacEWS/WebCore/inspector/InspectorDOMAgent.cpp:41:
/Users/eseidel/Projects/MacEWS/WebCore/platform/graphics/SimpleFontData.h:28:30: error: FontPlatformData.h: No such file or directory

[Dimitri Glazkov (Google)]

Comment on attachment 65262 [details]
platform/graphics/mac -> platform/graphics/cocoa

something is wrong with the diff. It's showing FontPlatformData* as removed, not copied.

[Jeremy Moskovich]

Created attachment 65411 [details]
Patch

[Jeremy Moskovich]

New patch uploaded with the help of the webkit-patch script, hopefully making for a better diff.  In case it's not clear from the changelog, the only changes in this patch are:
* Move 2 source files.
* Update WebCore XCodeproj & Chromium .gypi file to point to the new files.

[Dimitri Glazkov (Google)]

Comment on attachment 65411 [details]
Patch

ok.

[Jeremy Moskovich]

Created attachment 65847 [details]
Patch for landing

[WebKit Commit Bot]

Comment on attachment 65847 [details]
Patch for landing

Clearing flags on attachment: 65847

Committed r66329: <http://trac.webkit.org/changeset/66329>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[WebKit Review Bot]

http://trac.webkit.org/changeset/66329 might have broken Qt Linux Release

[Darin Adler]

I think this broke the build.

The failures here <http://build.webkit.org/builders/Chromium%20Mac%20Release/builds/12791/steps/compile-webkit/logs/stdio> look related to this.

[James Robinson]

It most definitely did.  Reverted at r66342.

[Jeremy Moskovich]

Created attachment 65878 [details]
Patch

[Kent Tamura]

Comment on attachment 65878 [details]
Patch

Looks OK.

[WebKit Commit Bot]

Comment on attachment 65878 [details]
Patch

Clearing flags on attachment: 65878

Committed r66358: <http://trac.webkit.org/changeset/66358>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[James Robinson]

We rely on header include path order to compile?  That's incredibly fragile :(.  Is there really no better way?

[Darin Adler]

This header include path dependency was added during the Chromium merge. Before that we used to use differently named header files and #if's in the central header but some Google folks wanted to use header paths because it scales better and does not require a single header with #ifs for each platform.