Progress towards resurrecting Mac CMake build
Created attachment 367865 [details] Patch
Comment on attachment 367865 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=367865&action=review > Source/WebCore/CMakeLists.txt:2041 > + COMMAND ${PERL_EXECUTABLE} ${JavaScriptCore_SCRIPTS_DIR}/xxd.pl WHLSLStandardLibrary ${WEBCORE_DIR}/Modules/webgpu/WHLSL/WHLSLStandardLibrary.txt ${WebCore_DERIVED_SOURCES_DIR}/WHLSLStandardLibrary.h ${WebCore_DERIVED_SOURCES_DIR}/WHLSLStandardLibrary.cpp Something isn't quite right here. It doesn't make WHLSLStandardLibrary.cpp
Created attachment 369027 [details] Patch
Comment on attachment 369027 [details] Patch Attachment 369027 [details] did not pass win-ews (win): Output: https://webkit-queues.webkit.org/results/12094875 New failing tests: http/tests/css/filters-on-iframes.html
Created attachment 369036 [details] Archive of layout-test-results from ews212 for win-future The attached test failures were seen while running run-webkit-tests on the win-ews. Bot: ews212 Port: win-future Platform: CYGWIN_NT-10.0-17763-3.0.5-338.x86_64-x86_64-64bit
Comment on attachment 369027 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=369027&action=review > Source/WebKitLegacy/PlatformMac.cmake:-434 > -WEBKIT_CREATE_FORWARDING_HEADERS(WebKitLegacy DIRECTORIES ${WebKitLegacy_FORWARDING_HEADERS_DIRECTORIES} FILES ${WebKitLegacy_FORWARDING_HEADERS_FILES}) Can we just get rid of this macro while doing this work? I know its still used in Source/WebKit but we should be able to copy there as well. > Source/WebKitLegacy/PlatformMac.cmake:430 > +WEBKIT_MAKE_FORWARDING_HEADERS(WebKitLegacy > + TARGET_NAME WebKitLegacyFrameworkHeaders > + DESTINATION ${WebKitLegacy_FRAMEWORK_HEADERS_DIR}/WebKitLegacy > + FILES ${WebKitLegacy_FORWARDING_HEADERS_FILES} > + FLATTENED > ) You can move this into the main CMakeLists.txt since both ports are using this.
Comment on attachment 369027 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=369027&action=review >> Source/WebKitLegacy/PlatformMac.cmake:-434 >> -WEBKIT_CREATE_FORWARDING_HEADERS(WebKitLegacy DIRECTORIES ${WebKitLegacy_FORWARDING_HEADERS_DIRECTORIES} FILES ${WebKitLegacy_FORWARDING_HEADERS_FILES}) > > Can we just get rid of this macro while doing this work? I know its still used in Source/WebKit but we should be able to copy there as well. Eventually. Not with this patch. >> Source/WebKitLegacy/PlatformMac.cmake:430 >> ) > > You can move this into the main CMakeLists.txt since both ports are using this. I'd like to avoid touching the windows build in this patch. We can combine those in a followup patch.
Created attachment 371430 [details] Patch
This gets JavaScriptCore and most of WebCore building. There are still some issues, but this is a good checkpoint to upstream and continue.
Comment on attachment 371430 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=371430&action=review r=me looks like a good start! Only concern is the library path. One thing I could use assistance with is creating a Find module for Apple specific frameworks for Apple builds (Win and Mac). Pop on IRC to discuss sometime. > Source/cmake/target/icu.cmake:-3 > -if (NOT TARGET ICU::data) Any reason for getting rid of the `if (NOT TARGET ICU::data)`? was something failing for you? Its fine as long as this is only included once. > Source/cmake/target/icu.cmake:9 > + set(ICU_I18N_LIBRARY /usr/lib/libicucore.dylib) > + set(ICU_UC_LIBRARY /usr/lib/libicucore.dylib) > + set(ICU_DATA_LIBRARY /usr/lib/libicucore.dylib) Is this always the path? Should we use a find_library for icucore.dylib in a private variable and then just set everything using that?
(In reply to Don Olmstead from comment #10) > Comment on attachment 371430 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=371430&action=review > > r=me looks like a good start! Only concern is the library path. > > One thing I could use assistance with is creating a Find module for Apple > specific frameworks for Apple builds (Win and Mac). Pop on IRC to discuss > sometime. > > > Source/cmake/target/icu.cmake:-3 > > -if (NOT TARGET ICU::data) > > Any reason for getting rid of the `if (NOT TARGET ICU::data)`? was something > failing for you? Its fine as long as this is only included once. It failed with the condition and didn't without the condition. I'm not sure why it was ever there. > > > Source/cmake/target/icu.cmake:9 > > + set(ICU_I18N_LIBRARY /usr/lib/libicucore.dylib) > > + set(ICU_UC_LIBRARY /usr/lib/libicucore.dylib) > > + set(ICU_DATA_LIBRARY /usr/lib/libicucore.dylib) > > Is this always the path? Should we use a find_library for icucore.dylib in a > private variable and then just set everything using that? This is always the path.
Comment on attachment 371430 [details] Patch Clearing flags on attachment: 371430 Committed r246126: <https://trac.webkit.org/changeset/246126>
All reviewed patches have been landed. Closing bug.
<rdar://problem/51455272>