[Development] The final mile

Hausmann Simon Simon.Hausmann at digia.com
Sun Dec 2 13:27:18 CET 2012


I can try to add some clarifications.

In beta2 we did the most developer-visible change with reards to the WebKit
library split by simply renaming QtWebKit to QtWebKitWidgets, which affects
.pro files and #include statements that use the module syntax.

Now we implemented a split for real, where we do have two Qt 5 C++ modules,
QtWebKit and QtWebKitWidgets. Classes like QWebView, QWebPage and
QGraphicsWebView that have intricate ties to classes from QtWidgets
consequently do live in QtWebKitWidgets and their dependencies to WebCore
internals are channeled through private API that QtWebKit exports. The QtWebKit C++ API
also provides classes that do not have any ties to QtWidgets but do indeed heavily
rely on WebCore internals, such as QWebElement or QWebSettings. These classes now
_remain_ in the QtWebKit C++ module.

It is our intention to make it so that when you write

    QT += webkitwidgets

in your .pro file, then it should imply QT += webkit, in order to maximize
source compatibility against Qt 4. This relies on people using #include
<qwebelement.h> or #include <QWebElement> instead of the module syntax, but
quite frankly I don't see any point in people using the module syntax in their
applications anyway.

Now it seems that on Linux and Windows this automatic dependency seems to work,
but it does seem to break down on Mac O X with frameworks. That at least would
explain the build failure in Qt Creator where the inclusion was #include <QWebSettings>
and the .pro file said QT += webkitwidgets but a QT += webkit was necessary to
fix the build.

Does anyone know if there is a way to make this automatic dependency also work
with Mac OS X frameworks or the way we create them in Qt?


From: development-bounces+simon.hausmann=digia.com at qt-project.org [development-bounces+simon.hausmann=digia.com at qt-project.org] on behalf of Koehne Kai [Kai.Koehne at digia.com]
Sent: Sunday, December 02, 2012 12:20 AM
To: Thiago Macieira; development at qt-project.org
Subject: Re: [Development] The final mile

> From: development-bounces+kai.koehne=digia.com at qt-project.org [development-bounces+kai.koehne=digia.com at qt-project.org] on behalf of Thiago Macieira [thiago.macieira at intel.com]
>> On segunda-feira, 19 de novembro de 2012 20.09.35, Knoll Lars wrote:
>> * WebKit library split (WebKit + WebKitWidgets)
>> This is a binary incompatible change, that has to go in for 5.0. Most of the
>> QtWebKit team is working on this, and I have good confidence that the
>> change will be and done in some time next week.
> This has apparently created source-incompatible changes which broke the
> package generation today.

Just to clarify this a bit, we had a build failure of qt-creator today in the qt-sdk packaging process where the compiler failed to find a "QWebSettings" include, although the .pro file did include "QT += webkitwidgets". The compiler call did actually contain -Iinclude/QtWebKitWidgets, but not -Iinclude/QtWebKit. This AFAIK only happened on Mac, and we're not yet sure what's the root cause (and whether it's a general Qt problem, or a problem with the way we compile Qt Creator / patch Qt on the build machines, which is a bit special ...).



PS: I pushed a fix that hopefully works around the issue by explicitly adding "QT+=webkit". So if anybody wants to give it a try locally, first revert https://codereview.qt-project.org/#change,41469 in qt-creator.

> Can someone post a summary of the targetted final state?
> If this is introducing major source incompatible changes, I'm going to request
> a new beta instead of an RC.
Development mailing list
Development at qt-project.org

More information about the Development mailing list