The EFL build is broken after https://trac.webkit.org/changeset/183659 because of an incremental build issue revealed by this patch. Dependencies seems to be set properly in cmake, but InspectorProtocolObjectes.h isn't regenerated, but it should be. CombinedDomains.json which is the main dependency of the generator script is regenerated and the build log says that te generator is called, but the header isn't regenrated. I can take a look on this bug on monday morning. If somebody has a quick fix before it, feel free to pick it up.
and the build log: https://build.webkit.org/builders/EFL%20Linux%2064-bit%20Release%20WK2%20%28Perf%29/builds/5494/steps/compile-webkit/logs/stdio
Good find =(. Your understanding of the steps looks correct as well.
I don't see anything obviously wrong either. It would help to see if CombinedDomains.json actually changed. The protocol generator will not touch output files if the generated output is the same. Another possibility is that there's a typo somewhere, and an old version of the header is being included instead of the newly generated one.
Something is weird here ... I can't reproduce it with doing clean build on 183658 and then incremental build on 183659. Unfortunately I didn't save the build directory of the bots, but I remember that CombinedDomains.json was regenerated and its content was correct, but the h/cpp files weren't regenerated. I'll investigate this strange bug soon.
(In reply to comment #4) > Something is weird here ... I can't reproduce it with doing > clean build on 183658 and then incremental build on 183659. Yeah, I carefully read over the cmake build steps and everything looked correct. Even if there was an exception during generation we should have failed the build step, so I am also baffled =)
I found the problem. http://trac.webkit.org/changeset/182243/trunk/Source/JavaScriptCore/CMakeLists.txt changed the path of the generated sources from WebKitBuild/Release/DerivedSources/JavaScriptCore to WebKitBuild/Release/DerivedSources/JavaScriptCore/inspector , but the old InspectorProtocolObjectes.h is left in WebKitBuild/Release/DerivedSources/JavaScriptCore and caused incremental build issue a month later. It isn't a build system bug, I don't think if we can handle this kind of situations without adding a sophisticated mechanism to remove stale files. Clean build solved the problem, so there is no problem since now.
(In reply to comment #6) > I found the problem. > > http://trac.webkit.org/changeset/182243/trunk/Source/JavaScriptCore/ > CMakeLists.txt changed the path of the generated sources from > WebKitBuild/Release/DerivedSources/JavaScriptCore to > WebKitBuild/Release/DerivedSources/JavaScriptCore/inspector , but the old > InspectorProtocolObjectes.h is left in > WebKitBuild/Release/DerivedSources/JavaScriptCore and caused incremental > build issue a month later. > > It isn't a build system bug, I don't think if we can handle this kind of > situations without adding a sophisticated mechanism to remove stale files. > > Clean build solved the problem, so there is no problem since now. Interesting, I think I have run into this before when I was modifying generator code for the same file. Maybe as a countermeasure, you can compute a hash of output directories and force a clean build if the hash changes. Not sure that this would be easy, though- isn't the "force clean" part of the builer interface, not CMake?