Since r291809, it's possible to import the same header from two different paths: once from its original source location and once from the SDK or build products, causing build failures due to duplicate types. This is because of WebKit's autogenerated headermap. It resolves migrated headers to the source locations IF they are imported through the <WebKit/…> prefix. If they are imported from <WebKitLegacy/…>, the headermap has no entry and they are resolved using normal search paths. Prior to r291809, migrated headers were never added to any headermaps, because they were produced by Make and Xcode was unaware of them.
<rdar://problem/90844690>
Created attachment 455783 [details] Patch
Comment on attachment 455783 [details] Patch Since the build rule script changes are hard to read, here they are expanded: +set -e if [ "${WK_PLATFORM_NAME}" != macosx ]; then echo "#import <WebKitLegacy/${INPUT_FILE_NAME}>" > "${SCRIPT_OUTPUT_FILE_0}" else "${SCRIPT_INPUT_FILE_0}" fi +echo "#import <WebKit/${INPUT_FILE_NAME}>" > "${SCRIPT_OUTPUT_FILE_1}" +echo "#import <WebKit/${INPUT_FILE_NAME}>" > "${SCRIPT_OUTPUT_FILE_2}" There are now two build rules, because any source file migrated from WebCore need special treatment. Since they've been migrated twice, they have two valid imports, <WebCore/foo> and <WebKitLegacy/foo>, that should be forwarded to <WebKit/foo>.
Committed r291900 (248893@main): <https://commits.webkit.org/248893@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 455783 [details].