If Qt was built with -no-script, applications using QtWebKit (which does work with -no-script) fail to build because qwebframe.h unconditionally does #include <QtScript/qscriptengine.h> (which doesn't exist in a -no-script build).
Created attachment 48013 [details] Fix Attaching fix
Attachment 48013 [details] did not build on qt: Build output: http://webkit-commit-queue.appspot.com/results/232341
Not sure what's causing the build bot failure... The command line from its report shows -DBUILD_WEBKIT is on the command line, and the modification is in #if !defined(QT_NO_SCRIPT) && !defined(BUILD_WEBKIT) I only tested the patch for building inside of Qt rather than the separate webkit tree though
This looks like it fails to build on the Qt Early Warning System (EWS) builder.
Comment on attachment 48013 [details] Fix > +#if !defined(QT_NO_SCRIPT) && !defined(BUILD_WEBKIT) > void addToJavaScriptWindowObject(const QString &name, QObject *object, QScriptEngine::ValueOwnership ownership); > +#endif Why the check for BUILD_WEBKIT? Also the Qt EWS bot indicates that this breaks the build because there's the equivalent #ifdef missing in qwebframe.cpp. (Yay for the EWS :)
The check for BUILD_WEBKIT is there because at build time (still talking about building QtWebKit inside the Qt tree, not about building it in the standalone tree), QtScript includes are available and the code can actually be built (that's also the reason for the absence of an equivalent ifdef in qwebframe.cpp -- at build time, QScriptEngine::ValueOwnership is availableand therefore it can be built). The thought behind allowing the 3-arg version of addToJavaScriptWindowObject to be built into the library even with -no-script was to try to preserve binary compatibility between versions built with -no-script and those built without -no-script -- but given the function is not very likely to actually work in -no-script mode, that may have been overly cautious.
*** Bug 33104 has been marked as a duplicate of this bug. ***
No update on this bug for a while. This isn't blocking the release anymore, but any patches will be welcomed for inclusion in the release branch :)
*** This bug has been marked as a duplicate of bug 52469 ***