RESOLVED FIXED 135167
[CMake] Avoid building WebCore with ANGLE's OpenGL/EGL headers
https://bugs.webkit.org/show_bug.cgi?id=135167
Summary [CMake] Avoid building WebCore with ANGLE's OpenGL/EGL headers
Zan Dobersek
Reported 2014-07-22 11:53:25 PDT
[CMake] Avoid building WebCore with ANGLE's OpenGL/EGL headers
Attachments
Patch (2.09 KB, patch)
2014-07-22 12:05 PDT, Zan Dobersek
no flags
Patch for landing (1.76 KB, patch)
2014-07-23 01:18 PDT, Zan Dobersek
no flags
Archive of layout-test-results from webkit-ews-15 for mac-mountainlion-wk2 (486.99 KB, application/zip)
2014-07-23 02:22 PDT, Build Bot
no flags
Archive of layout-test-results from webkit-ews-13 for mac-mountainlion-wk2 (486.42 KB, application/zip)
2014-07-23 03:24 PDT, Build Bot
no flags
Zan Dobersek
Comment 1 2014-07-22 12:05:47 PDT
Martin Robinson
Comment 2 2014-07-22 12:07:38 PDT
Comment on attachment 235304 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=235304&action=review > Source/WebCore/CMakeLists.txt:3608 > - list(APPEND WebCore_LIBRARIES ANGLESupport) > + target_include_directories(ANGLESupport PRIVATE "${THIRDPARTY_DIR}/ANGLE/include") > + target_link_libraries(WebCore ANGLESupport) Why use target_link_libraries directly here instead of WebCore_LIBRARIES?
Zan Dobersek
Comment 3 2014-07-22 12:16:26 PDT
Comment on attachment 235304 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=235304&action=review >> Source/WebCore/CMakeLists.txt:3608 >> + target_link_libraries(WebCore ANGLESupport) > > Why use target_link_libraries directly here instead of WebCore_LIBRARIES? In ChangeLog I mentioned this readds the ANGLESupport's include directories to WebCore. I retested it now and that might not be true. I'll re-check it and adjust accordingly before landing.
Zan Dobersek
Comment 4 2014-07-23 01:18:50 PDT
Created attachment 235347 [details] Patch for landing Testing through the EWS.
Build Bot
Comment 5 2014-07-23 02:22:51 PDT
Comment on attachment 235347 [details] Patch for landing Attachment 235347 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/6539658175447040 New failing tests: media/W3C/video/networkState/networkState_during_loadstart.html
Build Bot
Comment 6 2014-07-23 02:22:55 PDT
Created attachment 235349 [details] Archive of layout-test-results from webkit-ews-15 for mac-mountainlion-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: webkit-ews-15 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Build Bot
Comment 7 2014-07-23 03:24:27 PDT
Comment on attachment 235347 [details] Patch for landing Attachment 235347 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/6734099934871552 New failing tests: media/W3C/video/networkState/networkState_during_loadstart.html
Build Bot
Comment 8 2014-07-23 03:24:31 PDT
Created attachment 235350 [details] Archive of layout-test-results from webkit-ews-13 for mac-mountainlion-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: webkit-ews-13 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Zan Dobersek
Comment 9 2014-07-23 04:29:16 PDT
(In reply to comment #7) > (From update of attachment 235347 [details]) > Attachment 235347 [details] did not pass mac-wk2-ews (mac-wk2): > Output: http://webkit-queues.appspot.com/results/6734099934871552 > > New failing tests: > media/W3C/video/networkState/networkState_during_loadstart.html The patch doesn't affect this.
Zan Dobersek
Comment 10 2014-07-23 04:30:54 PDT
Comment on attachment 235347 [details] Patch for landing Clearing flags on attachment: 235347 Committed r171475: <http://trac.webkit.org/changeset/171475>
Zan Dobersek
Comment 11 2014-07-23 04:31:04 PDT
All reviewed patches have been landed. Closing bug.
Ryuan Choi
Comment 12 2014-07-24 16:48:48 PDT
Comment on attachment 235347 [details] Patch for landing View in context: https://bugs.webkit.org/attachment.cgi?id=235347&action=review > Source/WebCore/CMakeLists.txt:3607 > + target_include_directories(ANGLESupport PRIVATE "${THIRDPARTY_DIR}/ANGLE/include") target_include_directories is introduced at cmake 2.8.11 ( http://www.kitware.com/blog/home/post/492 ) And minimum required version is 2.8.3. Should we bump the cmake version for this?
Zan Dobersek
Comment 13 2014-07-29 06:36:00 PDT
(In reply to comment #12) > (From update of attachment 235347 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=235347&action=review > > > Source/WebCore/CMakeLists.txt:3607 > > + target_include_directories(ANGLESupport PRIVATE "${THIRDPARTY_DIR}/ANGLE/include") > > target_include_directories is introduced at cmake 2.8.11 ( http://www.kitware.com/blog/home/post/492 ) > And minimum required version is 2.8.3. > > Should we bump the cmake version for this? Thanks for the reminder. Bumping the required version in bug #135382.
Note You need to log in before you can comment on or make changes to this bug.