Bug 17796
| Summary: | Qt Windows buildbot failing because dftables script uses tools not present in that configuration | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Darin Adler <darin> |
| Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | Major | CC: | ddkilzer, hausmann, mrowe, staikos |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Mac | ||
| OS: | OS X 10.5 | ||
Darin Adler
The Qt Windows buildbot has been failing to build for weeks because the new dftables script relies on being able to invoke the C preprocessor, not available in that configuration.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
David Kilzer (:ddkilzer)
The dftables script was a compiled binary before, so I'm sure there is a C pre-processor available. It's just not available on the Windows path apparently.
Since I don't have access to this buildbot, nor do I have a Windows configuration for building Qt WebKit, I need some help figuring out how to "find" the C pre-processor.
Darin Adler
We could also try to make this work without a C preprocessor. The way it's currently set up is kind of arbitrary. The tables aren't really anything all that special; this could be rearranged so nobody has to parse a C file.
The basic idea would be to generate the constants from the script rather than having the script read the constants.
David Kilzer (:ddkilzer)
(In reply to comment #2)
> We could also try to make this work without a C preprocessor. The way it's
> currently set up is kind of arbitrary. The tables aren't really anything all
> that special; this could be rearranged so nobody has to parse a C file.
>
> The basic idea would be to generate the constants from the script rather than
> having the script read the constants.
I wanted to avoid this since it means the same logic would be duplicated in two different places, which means it could get out of sync later.
I also considered parsing the header file in pure Perl code, but didn't want to re-invent the wheel, e.g., cpp.
Simon Hausmann
The problem originally with the Qt port is that we can't rely on cpp being available as preprocessor in the system. We used to use a preprocessor that is built into a little helper tool that comes with Qt (moc), but that unfortunately has its limits. The macro substitution done for the chartables generation unfortunately doesn't work with the moc.
That's the bad part of the story. The good part is that we figured out that we can call cl.exe's preprocessor with /E just like g++ -E. We can abstract that in the qmake buildsystem and call the dftables script accordingly. So in other words the use of the preprocessor should be fine for the Qt build on Windows, provided that
1) The command can be configured through the commandline of the script (like with generate-bindings.pl.
2) The input to the preprocessor is a file, not stdin.
Simon Hausmann
With review from Adam Roben I have submitted
http://trac.webkit.org/projects/webkit/changeset/31030
Together with Darin's earlier fix about the shell piping the build bot runs again now. I have installed GNU CPP into the PATH of the build bot.
There is now another build problem left (rand_s), but at least the dftables problem is worked around for now.
I will try to change the Qt buildsystem to use cl.exe's preprocessor on Windows for the Qt build.
David Kilzer (:ddkilzer)
Thanks Simon!
David Kilzer (:ddkilzer)
(In reply to comment #5)
> There is now another build problem left (rand_s), but at least the dftables
> problem is worked around for now.
I believe this is Bug 17032.
Simon Hausmann
Fix for the problem of dftables using cpp for the Qt/Windows build landed in r34767 :)