Work items for the deployment of QtWebKit 2.x as a package separate from Qt

Requirements

• The distribution of the release should be available in both source and binaries
• A Qt user should be able to use the 2.x release as a replacement of the one shipped with their Qt SDK (at least for 4.6 and 4.7)
  • Components in Qt itself should use the new QtWebKit (e.g. declarative and assistant)
• It should be transparent to use the 2.x release with an application using the QT += webkit directive in their .pro file
• Binary packages should probably be installed on Windows using an installation program

Deployment mechanisms

There are two way of replacing QtWebKit in a Qt SDK (until Qt discouples itself completely from QtWebKit):

• Replace the QtWebKit sources:
  • Replace the content of src/3rdparty/webkit with the source package of QtWebKit 2.0
  • (re-)configure and (re-)compile Qt
• Replace the QtWebKit binaries:
  • Compile/download binaries of Qt
  • Compile/download binaries of QtWebKit 2.x
  • Install the binaries, headers and .prl of QtWebKit 2.x over the ones in the Qt installation directory

Limitations

Limitation of the sources replacement mechanism

• This might cause problems for people using Git. These people should be able to compile and install their own binaries anyway.

Limitation of the binary replacement mechanism

• Recompiling or uninstalling Qt might present problems
  • Reinstalling or recompiling Qt might leave extra headers from QtWebKit 2.x in the include/QtWebKit directory
  • Uninstalling might leave files and might cause problems especially if QtWebKit is also installed using a NSInstall application
• Because of the reasons above it will be tedious for the user to revert to the version of QtWebKit that was shipped with Qt.

Possible issues and questions to answer

• What will be the supported mechanism to deploy QtWebKit 2.0, source replacement? Binary replacement? Both?
• Should QtWebKit 2.0 be installed using an installation application on Windows? Qt itself doesn't have one, the Qt SDK has one, and QtWebKit will still be shipped with the SDK in the future. So how do we want to support the installation of this module until we have an official module installation mechanism?
• Qt 4.7 now includes QML which links against QtWebKit. We should think about how we will discouple it from QtWebKit in future versions
  Compared to Assistant which we wanted to distribute with Qt SDK but should still be easy to get out of the Qt repository once QtWebKit gets out.
• Any possible issues regarding linux distributions packaging? There will be common file paths between Qt and QtWebKit 2.x.
• How about freezing the API around a Qt SDK but allowing updating of the QtWebKit runtime? This would make the installation/upgrade/uninstallation easier.
  Then we would just need to update the dynamic libraries and to get the latest API we could provide a less official mechanism than QT += webkit
  Example including a .pri file in your application that would do something like:

  QT -= webkit
  INCLUDES += $$PWD/include/QtWebKit
  LIBS += -L$$PWD/lib
  LIBS += -lqtwebkit