Bug 119745 – [CMake] Always use the glslang_tab files from ANGLE instead of generating them.

• Component: ANGLE
• Status: RESOLVED WONTFIX

[Raphael Kubo da Costa (:rakuco)]

[CMake] Always use the glslang_tab files from ANGLE instead of generating them.

[Raphael Kubo da Costa (:rakuco)]

Created attachment 208626 [details]
Patch

[Raphael Kubo da Costa (:rakuco)]

Feedback (and optionally testing) here is appreciated: the existing version check that makes us not use the files we generate if using Bison 2.5 is too restrictive and breaks with Bison > 2.5.

While we could fix the check in CMake, just using the existing files provided by ANGLE allows us to simplify the code.

I've CC'ed Joshua Netterfield because of <https://bugs.webkit.org/show_bug.cgi?id=93487#c7>; I don't know what problems the BlackBerry guys were having at the time, but if the files provided by ANGLE have been generated with Bison 2.3 I don't see the problem happening again these days.

[Ming Xie]

The current BlackBerry port is using:
         ${THIRDPARTY_DIR}/ANGLE/src/compiler/glslang_lex.cpp
         ${THIRDPARTY_DIR}/ANGLE/src/compiler/glslang_tab.cpp

From http://trac.webkit.org/changeset/125496/trunk/Source/WebCore/CMakeLists.txt, it looks like the original problem was we included both:
        ${DERIVED_SOURCES_WEBCORE_DIR}/glslang.cpp
        ${DERIVED_SOURCES_WEBCORE_DIR}/glslang_tab.cpp
and
        ${THIRDPARTY_DIR}/ANGLE/src/compiler/glslang_lex.cpp 
        ${THIRDPARTY_DIR}/ANGLE/src/compiler/glslang_tab.cpp

Your patch should be fine.

[Alex Christensen]

When I updated ANGLE a few weeks ago, I made it so Bison 2.3-2.7 will work.  We are in the process of making all ports run Bison as part of the build process so that we can not include the generated files in the WebKit repository to make updating ANGLE easier.  Right now we have to run Bison as part of the update process, so please use the files from ${DERIVED_SOURCES_WEBCORE_DIR}.

[Raphael Kubo da Costa (:rakuco)]

Two questions:

 o Should <http://trac.webkit.org/changeset/153749> be reverted then?

 o How do I make the generated files build with Bison 3.0?

/b/webkit/efl/Debug/DerivedSources/WebCore/glslang_tab.cpp: In function 'int yyparse(TParseContext*)':
/b/webkit/efl/Debug/DerivedSources/WebCore/glslang_tab.cpp:1916:39: error: too few arguments to function 'int yylex(YYSTYPE*, TSourceLoc*, void*)'
/b/webkit/efl/Debug/DerivedSources/WebCore/glslang_tab.cpp:291:12: note: declared here
/b/webkit/efl/Debug/DerivedSources/WebCore/glslang_tab.cpp:1991:22: error: 'YYID' was not declared in this scope
/b/webkit/efl/Debug/DerivedSources/WebCore/glslang_tab.cpp:4754:18: error: 'YYID' was not declared in this scope

[Alex Christensen]

(In reply to comment #5)
> Two questions:
> 
>  o Should <http://trac.webkit.org/changeset/153749> be reverted then?
Not right now, but we should all be working to run bison and flex as part of the build to make updating easier (so we can remove ExpressionParser.cpp, Tokenizer.cpp, glslang_lex.cpp, glslang_tab.h, and glslang_tab.cpp).
> 
>  o How do I make the generated files build with Bison 3.0?
> 
> /b/webkit/efl/Debug/DerivedSources/WebCore/glslang_tab.cpp: In function 'int yyparse(TParseContext*)':
> /b/webkit/efl/Debug/DerivedSources/WebCore/glslang_tab.cpp:1916:39: error: too few arguments to function 'int yylex(YYSTYPE*, TSourceLoc*, void*)'
> /b/webkit/efl/Debug/DerivedSources/WebCore/glslang_tab.cpp:291:12: note: declared here
> /b/webkit/efl/Debug/DerivedSources/WebCore/glslang_tab.cpp:1991:22: error: 'YYID' was not declared in this scope
> /b/webkit/efl/Debug/DerivedSources/WebCore/glslang_tab.cpp:4754:18: error: 'YYID' was not declared in this scope
That's ANGLE's fault.  You should go complain to them.  Maybe add this to my issue: https://code.google.com/p/angleproject/issues/detail?id=449

[Raphael Kubo da Costa (:rakuco)]

It looks like carewolf is taking care of this in https://code.google.com/p/angleproject/issues/detail?id=462 and bug 119798 here.

[Raphael Kubo da Costa (:rakuco)]

Comment on attachment 208626 [details]
Patch

Removing the r? flag, as Alex said it makes more sense to just fix the files we process.