Bug 34519 – [Qt] Applications using QtWebKit fail to build if Qt was built with -no-script

• Component: New Bugs
• Status: RESOLVED DUPLICATE

[Bernhard Rosenkraenzer]

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

[Bernhard Rosenkraenzer]

Created attachment 48013 [details]
Fix

Attaching fix

[WebKit Review Bot]

Attachment 48013 [details] did not build on qt:
Build output: http://webkit-commit-queue.appspot.com/results/232341

[Bernhard Rosenkraenzer]

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

[Eric Seidel (no email)]

This looks like it fails to build on the Qt Early Warning System (EWS) builder.

[Simon Hausmann]

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 :)

[Bernhard Rosenkraenzer]

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.

[Kent Hansen]

*** Bug 33104 has been marked as a duplicate of this bug. ***

[Simon Hausmann]

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 :)

[Benjamin Poulain]

*** This bug has been marked as a duplicate of bug 52469 ***