Bug 153875 – Fix the EFL clean build after r196123

• Component: New Bugs
• Status: RESOLVED FIXED

[Csaba Osztrogonác]

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.

[Csaba Osztrogonác]

https://build.webkit.org/builders/EFL%20Linux%2064-bit%20Release%20WK2/builds/26477

[Chris Dumez]

Hmm, I updated CMakeList.txt to stop referring to JSDOMSettableTokenList.cpp though, odd.

[Chris Dumez]

Created attachment 270666 [details]
Patch

[Chris Dumez]

Letting EWS chew on this speculative fix.

[Csaba Osztrogonác]

(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.

[Csaba Osztrogonác]

(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?

[Chris Dumez]

(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.

[Chris Dumez]

(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.

[Csaba Osztrogonác]

(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.

[Chris Dumez]

Created attachment 270670 [details]
Patch

[Chris Dumez]

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.

[Chris Dumez]

Created attachment 270671 [details]
Patch

[Michael Catanzaro]

Comment on attachment 270671 [details]
Patch

Indeed, since it's in the unstable list, let's just drop it.

[Chris Dumez]

Comment on attachment 270671 [details]
Patch

Clearing flags on attachment: 270671

Committed r196136: <http://trac.webkit.org/changeset/196136>

[Chris Dumez]

All reviewed patches have been landed.  Closing bug.

[Csaba Osztrogonác]

(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.

[Csaba Osztrogonác]

(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?

[Csaba Osztrogonác]

(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?

[Chris Dumez]

(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).