In a few places, ANGLE declares classes that are explicitly not defined on certain platforms. Declarations and definitions should match so that failures are in ANGLE instead of the libraries that link it.
Created attachment 398431 [details] Patch
Note that there are important steps to take when updating ANGLE. See http://trac.webkit.org/wiki/UpdatingANGLE
Discovered this when working on the watchOS build. We end up declaring classes that aren't defined, which can create headaches for projects which attempt to link against those classes. Under the philosophy that errors should happen as soon as possible in the build process, I think we should guard the class declarations with the same macros that the class definitions are guarded with.
Thanks for finding and fixing these build issues - they look good to me. Have filed https://bugs.chromium.org/p/angleproject/issues/detail?id=4613 about upstreaming these changes into the ANGLE project to make future rolls of ANGLE into WebKit easier.
(In reply to Kenneth Russell from comment #4) > Thanks for finding and fixing these build issues - they look good to me. > > Have filed https://bugs.chromium.org/p/angleproject/issues/detail?id=4613 > about upstreaming these changes into the ANGLE project to make future rolls > of ANGLE into WebKit easier. There is a decent chance there will be more changes like this in the next week or two.
Committed r261176: <https://trac.webkit.org/changeset/261176> All reviewed patches have been landed. Closing bug and clearing flags on attachment 398431 [details].
<rdar://problem/62891185>
Reverted r261176 for reason: It broke the build Committed r261185: <https://trac.webkit.org/changeset/261185>
Trying this again, tested more builds this time.
Created attachment 402295 [details] Patch
Committed r263284: <https://trac.webkit.org/changeset/263284> All reviewed patches have been landed. Closing bug and clearing flags on attachment 402295 [details].