Bug 111267 – [Win] IDLParser.pm fails to parse OESTextureHalfFloat and causes a build failure

• Component: New Bugs
• Status: RESOLVED FIXED

[Ryosuke Niwa]

8>/home/buildbot/slave/WIN-DE~1/build/Source/WebCore/DerivedSources.make:1016: recipe for target `JSOESTextureHalfFloat.h' failed
8>make: *** [JSOESTextureHalfFloat.h] Error 2
8>make: *** Waiting for unfinished jobs….

It’s failing at:
http://trac.webkit.org/browser/trunk/Source/WebCore/bindings/scripts/IDLParser.pm#L196
196	    die "No definitions founds" unless @definitions;
197	

because this IDL is empty:
http://trac.webkit.org/browser/trunk/Source/WebCore/html/canvas/OESTextureHalfFloat.idl

[Ryosuke Niwa]

Created attachment 191133 [details]
Allow empty IDL definitions to fix clean builds

There are so many things I don’t understand about this patch. First off, what does OESTextureHalfFloat even mean? And second off, why is this IDL file empty? And finally, why is this even compiled on Apple Win?

But whatever. Here’s a trivial fix.

[Kentaro Hara]

Comment on attachment 191133 [details]
Allow empty IDL definitions to fix clean builds

According to the Web IDL spec, an empty IDL definition is acceptable: http://www.w3.org/TR/WebIDL/#prod-Definitions . So this patch looks OK.

However, an empty IDL definition does make zero sense in practice. Would you investigate about OESTextureHalfFloat ?

[WebKit Review Bot]

Comment on attachment 191133 [details]
Allow empty IDL definitions to fix clean builds

Clearing flags on attachment: 191133

Committed r144575: <http://trac.webkit.org/changeset/144575>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Ryosuke Niwa]

(In reply to comment #2)
> (From update of attachment 191133 [details])
>
> However, an empty IDL definition does make zero sense in practice. Would you investigate about OESTextureHalfFloat ?

Yeah. I don’t understan why we need this IDL. For starters, OESTextureHalfFloat is such a terrible :(

[Ryosuke Niwa]

It was added in https://bugs.webkit.org/show_bug.cgi?id=110818. I don’t understand why this was not announced on webkit-dev given that it’s an extension…