Bug 146740

I have been bitten by this. Re-running the build makes it continue, but that is not a proper solution. The build should work on the first try.

In the generated build.ninja file, I see: ############################################# # Order-only phony target for WebCorePlatformGTK build cmake_order_depends_target_WebCorePlatformGTK: phony || lib/libbmalloc.a lib/libWTFGTK.a lib/libjavascriptcoregtk-4.0.so lib/libWebCoreGTK.a DerivedSources/WebCore/WebKitGtkWaylandClientProtocol.c Which looks sane. But I also see: # Custom command for DerivedSources/WebCore/WebKitGtkWaylandClientProtocol.c build DerivedSources/WebCore/WebKitGtkWaylandClientProtocol.c: CUSTOM_COMMAND ../../Source/WebCore/platform/graphics/wayland/WebKitGtkWaylandClientProtocol.xml || lib/libWTFGTK.a lib/libWebCoreGTK.a lib/libbmalloc.a lib/libjavascriptcoregtk-4.0.so COMMAND = cd /home/mcatanzaro/WebKit/WebKitBuild/GNOME/Source/WebCore && wayland-scanner server-header < /home/mcatanzaro/WebKit/Source/WebCore/platform/graphics/wayland/WebKitGtkWaylandClientProtocol.xml > /home/mcatanzaro/WebKit/WebKitBuild/GNOME/DerivedSources/WebCore/WebKitGtkWaylandServerProtocol.h && wayland-scanner client-header < /home/mcatanzaro/WebKit/Source/WebCore/platform/graphics/wayland/WebKitGtkWaylandClientProtocol.xml > /home/mcatanzaro/WebKit/WebKitBuild/GNOME/DerivedSources/WebCore/WebKitGtkWaylandClientProtocol.h && wayland-scanner code < /home/mcatanzaro/WebKit/Source/WebCore/platform/graphics/wayland/WebKitGtkWaylandClientProtocol.xml > /home/mcatanzaro/WebKit/WebKitBuild/GNOME/DerivedSources/WebCore/WebKitGtkWaylandClientProtocol.c DESC = Generating ../../DerivedSources/WebCore/WebKitGtkWaylandClientProtocol.c Which I guess means DerivedSources/WebCore/WebKitGtkWaylandClientProtocol.c somehow has a bogus dependency on lib/libWebCoreGTK.a. I confirmed this by running 'ninja -t browse libWebCoreGTK.a' in my build directory, which showed libWebCoreGTK.a depends on lib/libWebCoreGTK.a depends on DerivedSources/WebCore/WebKitGtkWaylandClientProtocol.c depends on lib/libWebCoreGTK.a. So if I am reading this right, that is a cyclic dependency; the question is, why does it exist? DerivedSources/WebCore/WebKitGtkWaylandClientProtocol.c target is built using rule CUSTOM_COMMAND of ../../Source/WebCore/platform/graphics/wayland/WebKitGtkWaylandClientProtocol.xml lib/libWTFGTK.a (order-only) lib/libWebCoreGTK.a (order-only) lib/libbmalloc.a (order-only) lib/libjavascriptcoregtk-4.0.so (order-only) dependent edges build: Source/WebCore/CMakeFiles/WebCorePlatformGTK.dir/__/__/DerivedSources/WebCore/WebKitGtkWaylandClientProtocol.c.o cmake_order_depends_target_WebCorePlatformGTK

Copypasting from [1]: """The special rule name phony can be used to create aliases for other targets. For example: build foo: phony some/file/in/a/faraway/subdir/foo This makes ninja foo build the longer path. Semantically, the phony rule is equivalent to a plain rule where the command does nothing, but phony rules are handled specially in that they aren’t printed when run, logged (see below), nor do they contribute to the command count printed as part of the build process. phony can also be used to create dummy targets for files which may not exist at build time. If a phony build statement is written without any dependencies, the target will be considered out of date if it does not exist. Without a phony build statement, Ninja will report an error if the file does not exist and is required by the build.""" This rule: build DerivedSources/WebCore/WebKitGtkWaylandClientProtocol.c: CUSTOM_COMMAND ../../Source/WebCore/platform/graphics/wayland/WebKitGtkWaylandClientProtocol.xml || lib/libWTFGTK.a lib/libWebCoreGTK.a lib/libbmalloc.a lib/libjavascriptcoregtk-4.0.so Means that lib/libWebCoreGTK.a must be built before DerivedSources/WebCore/WebKitGtkWaylandClientProtocol.c if DerivedSources/WebCore/WebKitGtkWaylandClientProtocol.c does not already exist. Everything after the || is an order-only dependency, meaning that DerivedSources/WebCore/WebKitGtkWaylandClientProtocol.c does not need to be rebuilt when lib/libWebCoreGTK.a changes. [2] I can find no justification for why those dependencies exist. I wonder if it's a CMake bug. [1] https://martine.github.io/ninja/manual.html#_the_literal_phony_literal_rule [2] https://martine.github.io/ninja/manual.html#ref_dependencies

But it looks like it's normal that these dependencies exist for all WebCore derived sources. E.g. # Custom command for DerivedSources/WebCore/JSTypeConversions.cpp build DerivedSources/WebCore/JSTypeConversions.cpp DerivedSources/WebCore/JSTypeConversions.h: CUSTOM_COMMAND ../../Source/WebCore/bindings/scripts/generate-bindings.pl ../../Source/WebCore/bindings/scripts/CodeGenerator.pm ../../Source/WebCore/bindings/scripts/CodeGenerator.pm ../../Source/WebCore/bindings/scripts/CodeGeneratorJS.pm ../../Source/WebCore/bindings/scripts/IDLParser.pm ../../Source/WebCore/bindings/scripts/InFilesParser.pm ../../Source/WebCore/bindings/scripts/preprocessor.pm DerivedSources/WebCore/supplemental_dependency.tmp ../../Source/WebCore/bindings/scripts/IDLAttributes.txt DerivedSources/WebCore/DOMWindowConstructors.idl ../../Source/WebCore/bindings/scripts/CodeGeneratorJS.pm ../../Source/WebCore/testing/TypeConversions.idl || lib/libANGLESupport.a lib/libWTFGTK.a lib/libWebCoreGTK.a lib/libbmalloc.a lib/libjavascriptcoregtk-4.0.so OK, I don't understand this at all.

My guess is, this is http://www.cmake.org/Bug/view.php?id=15454 Which is fixed in CMake 3.3. So not a WebKit bug, and the workaround is to use make.

Thanks for the investigation. This information is very useful. Unfortunately, not only the bots and EWS machines use ninja, but also many developers. CMake 3.3 isn't even released, so depending on it is not an option. Neither is an option telling developers to not use ninja (or to run the build twice) if they want to use the default build options. I will try to find a workaround, because this is blocker for bug 146057

(In reply to comment #5) > My guess is, this is http://www.cmake.org/Bug/view.php?id=15454 > > Which is fixed in CMake 3.3. So not a WebKit bug, and the workaround is to > use make. That can't be right, because in comment #4 I observed that the dependencies looked just like all our other DerivedSources deps, none of which have this problem. I think Carlos Lopez has found the real problem; I'll let him post about it.

I hit this error too, but the PlatformDisplayWayland.h header (which includes WebKitGtkWaylandClientProtocol.h) wasn't included from PlatformDisplay.cpp, but from some other file in a library other than libWebCorePlatformGTK. The simplest solution is to move the WebKitGtkWaylandClientProtocol.h header inclusion into the PlatformDisplayWayland.cpp file, and use a forward declaration for the wl_webkitgtk struct in the header. On a side note, PlatformDisplayX11.cpp is built into libWebCore, while PlatformDisplay.cpp and PlatformDisplayWayland.cpp are built into libWebCorePlatformGTK. Would be nice to build these into the same library if possible.

(In reply to comment #8) > On a side note, PlatformDisplayX11.cpp is built into libWebCore, while > PlatformDisplay.cpp and PlatformDisplayWayland.cpp are built into > libWebCorePlatformGTK. Would be nice to build these into the same library if > possible. Yes, this is the issue here I think. Including PlatformDisplayWayland.cpp in libWebCore instead of libWebCorePlatformGTK fixes this bug. I will upload a patch.

Created attachment 256479 [details] Patch

reviewers, any comments on this patch? Thanks

Comment on attachment 256479 [details] Patch Sensible.

Comment on attachment 256479 [details] Patch Clearing flags on attachment: 256479 Committed r186768: <http://trac.webkit.org/changeset/186768>

All reviewed patches have been landed. Closing bug.