WebKit fails to build with MinGW compiler after changeset 144024
Build fails with the following error from Source/WebCore/page/scrolling/ScrollingCoordinator.cpp:31: /usr/i686-w64-mingw32/sys-root/mingw/include/winsock2.h:15:2: warning: #warning Please include winsock2.h before windows.h [-Wcpp] Source/WebCore/page/scrolling/ScrollingCoordinator.cpp: In static member function 'static WebCore::GraphicsLayer* WebCore::ScrollingCoordinator::scrollLayerForScrollableArea(WebCore::ScrollableArea*)': Source/WebCore/page/scrolling/ScrollingCoordinator.cpp:277:28: error: 'class WebCore::ScrollableArea' has no member named 'layerForScrolling' Source/WebCore/page/scrolling/ScrollingCoordinator.cpp: In static member function 'static WebCore::GraphicsLayer* WebCore::ScrollingCoordinator::horizontalScrollbarLayerForScrollableArea(WebCore::ScrollableArea*)': Source/WebCore/page/scrolling/ScrollingCoordinator.cpp:282:28: error: 'class WebCore::ScrollableArea' has no member named 'layerForHorizontalScrollbar' Source/WebCore/page/scrolling/ScrollingCoordinator.cpp: In static member function 'static WebCore::GraphicsLayer* WebCore::ScrollingCoordinator::verticalScrollbarLayerForScrollableArea(WebCore::ScrollableArea*)': Source/WebCore/page/scrolling/ScrollingCoordinator.cpp:287:28: error: 'class WebCore::ScrollableArea' has no member named 'layerForVerticalScrollbar' Source/WebCore/page/scrolling/ScrollingCoordinator.cpp:288:1: warning: control reaches end of non-void function [-Wreturn-type] Source/WebCore/page/scrolling/ScrollingCoordinator.cpp: In static member function 'static WebCore::GraphicsLayer* WebCore::ScrollingCoordinator::horizontalScrollbarLayerForScrollableArea(WebCore::ScrollableArea*)': Source/WebCore/page/scrolling/ScrollingCoordinator.cpp:283:1: warning: control reaches end of non-void function [-Wreturn-type] Source/WebCore/page/scrolling/ScrollingCoordinator.cpp: In static member function 'static WebCore::GraphicsLayer* WebCore::ScrollingCoordinator::scrollLayerForScrollableArea(WebCore::ScrollableArea*)': Source/WebCore/page/scrolling/ScrollingCoordinator.cpp:278:1: warning: control reaches end of non-void function [-Wreturn-type] make[1]: *** [Source/WebCore/page/scrolling/libWebCore_la-ScrollingCoordinator.lo] Błąd 1 make[1]: Opuszczenie katalogu `/home/pawel/src/webkit' make: *** [all] Błąd 2
Created attachment 191136 [details] Patch
Comment on attachment 191136 [details] Patch Seems like this is fixing the problem in the wrong place. Can you just give ScrollableArea empty (inline return null) definitions in the !USE(ACCELERATED_COMPOSITING) case? Then the callers wouldn't have to look so ugly.
Chromium seems to be the only user of these methods, I think not defining them at all if AC is off makes sense (as opposed to defining an empty version for the non-AC case).
Created attachment 191545 [details] Patch
Comment on attachment 191545 [details] Patch Not sure this has anything to do with the MinGW compiler.
Comment on attachment 191545 [details] Patch I didn’t see James Robinson’s earlier comment; James, feel free to change to review- if you disagree with me. It seems to me that GraphicsLayer should only exist when USE(ACCELERATED_COMPOSITING) is true. I’m surprised that is not the case!
(In reply to comment #7) > (From update of attachment 191545 [details]) > I didn’t see James Robinson’s earlier comment; James, feel free to change to review- if you disagree with me. > > It seems to me that GraphicsLayer should only exist when USE(ACCELERATED_COMPOSITING) is true. I’m surprised that is not the case! There's another patch that fixes this - lemme find it.
I believe the patch in https://bugs.webkit.org/show_bug.cgi?id=111306 takes care of this. The GraphicsLayer type's definition is guarded by USE(ACCELERATED_COMPOSITING) but there are declarations of the type outside the guard in various places. I guess it's to keep the #ifdeffage down in interface definitions, but perhaps Simon knows the history more concretely here.
I think the more general issue is very few ports compile without USE(ACCELERATED_COMPOSITING) these days (for instance, none of the EWS bots do) so it's harder to keep this configuration compiling.
Nothing necessarily wrong with this patch, but it'll be handled by patch in bug 111306 just as well. *** This bug has been marked as a duplicate of bug 111306 ***