[Development] Modules in qtbase (was: Re: new "debugsupport" module and API)

[Sze Howe Koh]

On 13 May 2014 14:17, Kurt Pattyn <pattyn.kurt at gmail.com> wrote:
>
>
>> On 13 May 2014, at 08:01, Knoll Lars <Lars.Knoll at digia.com> wrote:
>>
>>> On 12/05/14 22:40, "Thiago Macieira" <thiago.macieira at intel.com> wrote:
>>>
>>>> Em seg 12 maio 2014, às 19:35:24, Oswald Buddenhagen escreveu:
>>>>> On Mon, May 12, 2014 at 08:39:37AM -0700, Thiago Macieira wrote:
>>>>>> Em seg 12 maio 2014, às 11:48:21, Ulf Hermann escreveu:
>>>>>> The following changes create a debugsupport module with public API
>>>> in
>>>>>
>>>>>> qtbase:
>>>>> Please create a new module. This doesn't need to be in qtbase.
>>>>
>>>> given that the two quick implementations will depend on it, it makes
>>>> little sense to split it out, given what else is in qtbase.
>>>
>>> Neither implementation is in qtbase, so I don't see the logic in that
>>> argument. Yes, it *can* be in qtbase, but I don't see why it *should* be.
>>>
>>> I want to hear a reason of why it should.
>>
>> Yes, let’s not make qtbase even bigger if we can avoid it. It’s hard
>> enough to work with as it is.
>>>
>>> In that light:
>>>
>>> QtXml is there for historical reasons: there was code that needed it
>>> (including QtDBus). It can probably be moved out now.
>>>
>>> QtOpenGL and QtConcurrent are also historical and can probably be moved
>>> out
>>> too. Especially since those three aren't getting almost any updates, it
>>> makes
>>> sense to do it.
>>>
>>> QtDBus needs to stay because the XCB plugin needs it for some D-Bus
>>> protocols
>>> (notifications, the new systray protocol, etc.)
>>>
>>> The rest of the libraries in qtbase are really base stuff.
>>
>> Actually I was thinking about splitting a few more things out. In addition
>> to the ones mentioned above, I believe we would benefit from splitting
>> QtNetwork out into it’s own module. The reason is that QtNetwork is
>> responsible for many of the failing CI runs due to the inherent
>> instability on the network tests. Splitting out the module should help
>> make many of the qtbase integrations go more smoothly.
> This makes sense. Maybe the WebSockets module can be integrated into the network module in that case?
> I would also propose to move some code into qtbase: e.g. the matrix classes that are now in QtGui.
>
> Cheers,
>
> Kurt

The term "module" has multiple meanings in the discussion.

1) Qt module (e.g. Qt Core, Qt GUI, Qt WebSockets)
2) Git submodule (e.g. qtbase.git, qtwebsockets.git)

There is a one-to-one relationship between Qt modules and compiled libraries:
  * Qt Core <-> Qt5Core.dll
  * Qt GUI <-> Qt5Gui.dll
  * Qt WebSockets <-> Qt5WebSockets.dll

However, Git submodules can contain multiple Qt modules. For example,
qtbase.git contains Qt Core, Qt GUI, etc. (so the matrix classes in Qt
GUI are already in qtbase.git ;-) ) See
http://qt-project.org/wiki/Qt_5_Structure for a full list -- it needs
updating, but should be helpful.

Note: There is no Qt module called "Qt Base".

When Thiago said "Please create a new module", he meant "Please create
a new Git submodule". Qt modules can safely be moved between Git
submodules, but classes cannot be moved between Qt modules because
that will break binary compatibility. That means Qt WebSockets cannot
be merged with Qt Network, and the matrix classes cannot be moved out
of Qt GUI, until Qt 6.

(If I remember correctly, QXmlStreamReader/Writer were successfully
moved from Qt XML to Qt Core in Qt 4.4, but it was messy)


To add to the confusion, there's also a third meaning for "module" in Qt:
3) QML module (e.g. QtQuick, QtQuick.Particles, QtAudioEngine)

* The QtQuick QML module is associated with the Qt Quick Qt module
* The QtQuick.Particles QML module is associated with the Qt Quick Qt module
* The QtAudioEngine QML module is associated with the Qt Multimedia Qt module

Note: There is no Qt module called "Qt Audio Engine".


Regards,
Sze-Howe