Bug 233977 – [MacCatalyst] Fix build after r286603

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Myles C. Maxfield]

[MacCatalyst] Fix build after r286603

[Myles C. Maxfield]

Created attachment 446300 [details]
Patch

[EWS Watchlist]

Note that there are important steps to take when updating ANGLE. See https://trac.webkit.org/wiki/UpdatingANGLE

[EWS]

Committed r286645 (244958@main): <https://commits.webkit.org/244958@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 446300 [details].

[Radar WebKit Bug Importer]

<rdar://problem/86194597>

[Darin Adler]

Comment on attachment 446300 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=446300&action=review

> Source/ThirdParty/ANGLE/src/common/platform.h:135
> +#            undef TARGET_OS_IOS

How is it safe to do this? Don’t system headers depend on how these macros are set? Setting them the way ANGLE code expects could fix ANGLE, but then break the system headers?

You said something about long-term fix, but doing it this way may work now, but seems like it could cause new problems at any time when Apple system headers are changed.

[Myles C. Maxfield]

Comment on attachment 446300 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=446300&action=review

>> Source/ThirdParty/ANGLE/src/common/platform.h:135
>> +#            undef TARGET_OS_IOS
> 
> How is it safe to do this? Don’t system headers depend on how these macros are set? Setting them the way ANGLE code expects could fix ANGLE, but then break the system headers?
> 
> You said something about long-term fix, but doing it this way may work now, but seems like it could cause new problems at any time when Apple system headers are changed.

Yes, you’re absolutely right, and I’m working with Kyle to get this fixed properly as soon as we can. This patch is just to allow developers to continue developing rather than hitting a 100% repro build failure.