[chromium] WebKit::setColorNames is a client API
Created attachment 128819 [details]
I moved WebColor into Platform/ since it's needed for some compositor APIs, but upon reflection WebKit::setNamedColors is really logically a client API. This moves setNamedColors and the WebColorName enums back into the client space. I can update the chromium headers as a follow-up and then remove the platform/WebColorName.h forwarding header. I think WebColor as a typedef for unsigned should remain in both APIs.
Actually, I should probably move the setNamedColors() impl from WebColor.cpp to WebColorName.cpp if I do this. Will update patch...
Created attachment 128820 [details]
Committed r108860: <http://trac.webkit.org/changeset/108860>
Rolled out in r108865. From http://build.chromium.org/p/chromium.webkit/builders/Linux%20Tests/builds/18924/steps/compile/logs/stdio:
In file included from ./third_party/WebKit/Source/WebKit/chromium/public/platform/WebColorName.h:29,
./third_party/WebKit/Source/WebKit/chromium/public/platform/../WebColorName.h:34:29:error: public/WebColor.h: No such file or directory
./third_party/WebKit/Source/WebKit/chromium/public/platform/../WebColorName.h:35:30:error: public/WebCommon.h: No such file or directory
Code on the chromium side that #inclues WebColorName.h depends on the WebKit client API but not the Platform API, so it doesn't have the Platform API's include paths. I think the fix is to use full relative include paths like "../../../Platform/chromium/public/WebColor.h" in WebKit/chromium/public/WebColorName.h or to jigger the dependencies around so that every target that depends on the WebKit client API also has the Platform API's include paths.
Committed r108877: <http://trac.webkit.org/changeset/108877>