https://trac.webkit.org/changeset/196123 broke the clean build on EFL. error log: c++: error: DerivedSources/WebCore/JSDOMSettableTokenList.cpp: No such file or directory c++: fatal error: no input files compilation terminated. The problem is that DOMSettableTokenList.idl is guarded since r196123 and DerivedSources/WebCore/JSDOMSettableTokenList.cpp isn't generated at all. EWS and buildbot didn't notice this error, because the stale generated file remained in WebKitBuild. cc-ing EFL maintainers to fix the broken build.
https://build.webkit.org/builders/EFL%20Linux%2064-bit%20Release%20WK2/builds/26477
Hmm, I updated CMakeList.txt to stop referring to JSDOMSettableTokenList.cpp though, odd.
Created attachment 270666 [details] Patch
Letting EWS chew on this speculative fix.
(In reply to comment #2) > Hmm, I updated CMakeList.txt to stop referring to JSDOMSettableTokenList.cpp > though, odd. AFAIK JSDOMSettableTokenList.cpp name is generated from DOMSettableTokenList.idl filename and automatically added to the build by a cmake macro.
(In reply to comment #4) > Letting EWS chew on this speculative fix. Unfortunately EWS won't be able to check it, because it is an incremental build issue. The stale generated cpp is still on the bot. Doesn't GTK port need this idl?
(In reply to comment #5) > (In reply to comment #2) > > Hmm, I updated CMakeList.txt to stop referring to JSDOMSettableTokenList.cpp > > though, odd. > > AFAIK JSDOMSettableTokenList.cpp name is generated from > DOMSettableTokenList.idl > filename and automatically added to the build by a cmake macro. Ok, that's what I figured. So my speculative fix drops the idl file from the CMakeLists.txt. EFL does not need to know about this IDL file at all. GTK does care about this IDL though but I am hoping the change is fine because the PlatformGTK.cmake file includes DOMSettableTokenList.idl still.
(In reply to comment #7) > (In reply to comment #5) > > (In reply to comment #2) > > > Hmm, I updated CMakeList.txt to stop referring to JSDOMSettableTokenList.cpp > > > though, odd. > > > > AFAIK JSDOMSettableTokenList.cpp name is generated from > > DOMSettableTokenList.idl > > filename and automatically added to the build by a cmake macro. > > Ok, that's what I figured. So my speculative fix drops the idl file from the > CMakeLists.txt. EFL does not need to know about this IDL file at all. > > GTK does care about this IDL though but I am hoping the change is fine > because the PlatformGTK.cmake file includes DOMSettableTokenList.idl still. Hmm, GTK EWS seems unhappy after all. I am unsure how to fix it then.
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #5) > > > (In reply to comment #2) > > > > Hmm, I updated CMakeList.txt to stop referring to JSDOMSettableTokenList.cpp > > > > though, odd. > > > > > > AFAIK JSDOMSettableTokenList.cpp name is generated from > > > DOMSettableTokenList.idl > > > filename and automatically added to the build by a cmake macro. > > > > Ok, that's what I figured. So my speculative fix drops the idl file from the > > CMakeLists.txt. EFL does not need to know about this IDL file at all. > > > > GTK does care about this IDL though but I am hoping the change is fine > > because the PlatformGTK.cmake file includes DOMSettableTokenList.idl still. > > Hmm, GTK EWS seems unhappy after all. I am unsure how to fix it then. maybe these lines in the GTK cmake system helps: (absolutely speculative) list(APPEND WebCore_IDL_FILES html/DOMSettableTokenList.idl ) Otherwise EFL clean build is happy with this change.
Created attachment 270670 [details] Patch
Comment on attachment 270670 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=270670&action=review > Source/WebCore/PlatformGTK.cmake:-718 > - html/DOMSettableTokenList.idl Someone from the GTK port should confirm but I think I was told it is fine to drop as long as they are in the "Unstable" API list.
Created attachment 270671 [details] Patch
Comment on attachment 270671 [details] Patch Indeed, since it's in the unstable list, let's just drop it.
Comment on attachment 270671 [details] Patch Clearing flags on attachment: 270671 Committed r196136: <http://trac.webkit.org/changeset/196136>
All reviewed patches have been landed. Closing bug.
(In reply to comment #14) > Comment on attachment 270671 [details] > Patch > > Clearing flags on attachment: 270671 > > Committed r196136: <http://trac.webkit.org/changeset/196136> It broke the Apple Mac cmake build.
(In reply to comment #16) > > Committed r196136: <http://trac.webkit.org/changeset/196136> > > It broke the Apple Mac cmake build. The cmake build is still broken a week ago due to this change. Is the Mac cmake build maintained?
(In reply to comment #17) > (In reply to comment #16) > > > Committed r196136: <http://trac.webkit.org/changeset/196136> > > > > It broke the Apple Mac cmake build. > > The cmake build is still broken a week ago due to this change. > Is the Mac cmake build maintained? ping?
(In reply to comment #18) > (In reply to comment #17) > > (In reply to comment #16) > > > > Committed r196136: <http://trac.webkit.org/changeset/196136> > > > > > > It broke the Apple Mac cmake build. > > > > The cmake build is still broken a week ago due to this change. > > Is the Mac cmake build maintained? > > ping? I landed a couple of fixes but there are still more issues (unrelated to my change).