This is a followup post to the Qt is going modular post in October. Work has gone steadily and we now have modularized most of the big pieces.

In the diagram below, you can see the current split. The modules that were not originally part of Qt have not been illustrated.

Some design decisions:

• No source dependencies between modules are allowed, only header dependencies.
• There are still many modules in the QtKernel repository. The reason for this choice is that separating these modules is very hard from a technical standpoint. There are numerous, private dependencies between them (especially QtCore and QtGui), and while we could keep them in separate repositories, it just doesn't make sense when the dependencies are as heavy as they are. Truly separating them on a source code level would take too long, and right now it is more important that the rest of Qt is modularized. There is also nothing preventing us from modularizing them in a later project.
• Class documentation stays with their module, since it is inside .cpp files, and naturally belong there anyway. Overview documentation and the qdoc tool itself go in a separate repository.
• Examples and demos stay with the modules that they demonstrate, with a few exceptions when they depend on many modules. qtdemo is one such exception, and it will go into the doc repository.
• Autodetection of platform features is still done by the configure script in QtKernel, even if it is used by a different module. This is again to save time on the project. The goal here is that the new maintainers of each module will start transitioning to their own configure scripts (or something different) when the switch to a modular Qt has been made. For example, QtWebKit already has the build-webkit script.
• "git submodule" has been chosen as the way to provide a master repository containing all of the modularized ones.

Current status:

Most of the things in Qt have been modularized, and are building in Linux. The three big pieces of work we are currently looking at is building for other platforms, running autotests and adapting the modularization process to the Qt master branch (it is currently based on 4.7).

What will happen at the switch

Since Modularization is a very important project for us, we want to make the switch as soon as it is possible. This means that some work may be postponed until after the switch as long as it does not interfere with development. There is no exact date set, but somewhere between one and two months from now should be a good estimate. There will be more news about this when a solid date has been set.

When the switch takes place, what will happen is that all development in the existing Qt repository will be closed. No more commits allowed. Following that, new repositories will appear according to the diagram above. The old Qt repository will be archived so that it can be used to look at old history using the "Git graft" mechanism. However, the new repositories will all start out without any history of their own, with the exception of QtWebKit, which is already a separate repository and based on the original WebKit history.

This means that merge requests will start going to each individual module, and existing merge requests will unfortunately have to be resubmitted according to the new module layout.

Certainly there will be some difficulties in the first phases, but hopefully when they're ironed out, we'll have a Qt repository structure that is easier and more enjoyable to use and work on.