Qt Modules: any algorithm to exactly identify then in a repository ?

user0353

First of all, being this my first post on the forum, my sincere congrats to all the people making the Qt Framework for the great job over decades.

I know this would have little to no practical relevance, but out of curiosity, with the framwork becoming more nad more powerful over the years, but also more complex internally, is there nowdays an algorithm allowing to exactly identifies the modules in a repository (or at least those meant for the framework user) and maybe also matching them to the related documetation pages and maybe, furthermore, to the installed binaries tree (say for example under Windows) ?

For example, the qtdeclarative repo v6.7.0 has a nice readme listing the included modules (and not all repos has such a readme), though not all of those modules appears also in the main list at https://doc.qt.io/qt-6/qtmodules.html; moreover it seems i can find cmake commands like qt_internal_add_qml_module for most of the modules listed in the readme, but many of them seems to be marked "Private" by the parameters passed to such cmake command even if they have a documentation page listing public APIs.

Similarly, in a Windows installation, in <...>/bin/../modules, appears what seems an exhaustive modules list by mean of a json file for each one of them, though again also many modules having a public API have a"Private" suffix to their name, those json files.

All of that looks kind of confusing to me, likely because i didn't follow closely enough the development of Qt6 and maybe especially of the QML world.

SGaist

Hi and welcome to devnet,

Most of the modules are "single" modules. The main exceptions being QtBase, QtMultimedia and QtDeclarative.

As for the private in the cmake command, it has nothing to do with the state of the API. Qt private APIs are just not exposed. It's to tell the linker that you don't want to expose that dependency. See this StackOverflow answer.

user0353

Thank you for the reply,
I indeed i knew that, but a quick recap never hurts. :)

I'll try to rephrase more precisely.

With "module", below i stricly mean a "Qt module" (e.g. "Qt Core", "Qt Quick" ... ), regardless it being composed of a single library, multiple libraries, executable tool(s), QML components, plugins, a mix of that, etc.

Say I have a qt repository (maybe qtdeclarative, for example),
how do I detrministically (and maybe programmatically) find out which public (as in to be used by the framework user) modules it contains, which files are part of each module, and maybe also the offcial documentation page of each module ?

Say i have a Qt installation tree, how do I find out the same things listed above ?

PS:
the 'Private' thing with CMake files i was referring to is something like
(https://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/particles/CMakeLists.txt?h=v6.7.0):

qt_internal_add_qml_module(QuickParticlesPrivate
    URI "QtQuick.Particles"
    VERSION "${PROJECT_VERSION}"
    PLUGIN_TARGET particlesplugin
    CLASS_NAME QtQuick2ParticlesPlugin
    DEPENDENCIES
        QtQuick/auto
    INTERNAL_MODULE
    SOURCES
    ...

(note the "Private" suffix in the "QuickParticlesPrivate" name and the "INTERNAL_MODULE" 'tag')

And, similarry, for example in an installation on Windows, we find <...>\bin...\modules\QuickParticlesPrivate.json.

But, the "Qt Quick Particles" module has a public API:
https://doc.qt.io/qt-6/qtquick-particles-qmlmodule.html

Christian Ehrlicher

@user0353 said in Qt Modules: any algorithm to exactly identify then in a repository ?:

maybe also the offcial documentation page of each module ?

Whats wrong with https://doc.qt.io/qt.html? There you can see all modules. And when you want to know in which module a class can be found then search in the documentation and you can read it what it's needed to add to CMakeLists.txt so you can use it.

SGaist

The code bases are mostly structured the same.

Files with a _p prefix are private implementation so nothing that shall be considered stable there. Others should be the public API. The documentation of each class is in the implementation. Other parts are found in the docs folder(s).

user0353

@Christian-Ehrlicher said in Qt Modules: any algorithm to exactly identify then in a repository ?:

@user0353 said in Qt Modules: any algorithm to exactly identify then in a repository ?:

maybe also the offcial documentation page of each module ?

Whats wrong with https://doc.qt.io/qt.html? There you can see all modules. And when you want to know in which module a class can be found then search in the documentation and you can read it what it's needed to add to CMakeLists.txt so you can use it.

Nothing wrong with that, great documentation.

As stated in the first post my question was mainly out curiosity, also about the internal 'physical' organization of the framework (or at least of the public modules).

https://doc.qt.io/qt-6/qtmodules.html
does not seem to list really all of the modules, for example in
https://code.qt.io/cgit/qt/qtdeclarative.git/tree/README.md?h=v6.7.0
you see some modules you won't find in the front page above; then, yes the readme also points to a documentation page for each modules it lists, but (just a random example) i won't search https://doc.qt.io for "Qt Quick Local Storage" if i don't know such a module exists. And not all repos have a readme like the one in qtdeclarative.

Moreover, there seem to be no exact match between
https://doc.qt.io/qt-6/qtmodules.html
and any of the following
https://www.qt.io/product/features?qt-edition=qt-community-edition
https://www.qt.io/terms-conditions/qt-dev-framework/exhibit-1 (no exact match even if keeping in mind that the table there do not list the community edition of the framework)
https://wiki.qt.io/Maintainers

In other words, I didn't find so far a documentation page nor an 'algorithm' (applied to the repos or to an installation tree) which would let you precisely deuduce the following mapping:
<repos> <-> source (and other types) files for each module <-> doc page for each module <-> files for each module in an installation tree.

SGaist

It's more or less what I described. The classes doc within the code. The general doc in the doc folders. What ends with _p is private implementation.

user0353

Thank you, and that is clear.

Though that is not enough to identify all the modules in a given repo (or installation tree) and all the files belonging to each module.
Unless the general rule (for the repos at least) is as simple as "for each repo, any /src/<subdir> having in turn a subdir. named doc is a module, the module name is in the file /src/<subdir>/..., the files, if any, part of the module but external to /src/<subdir> are listed in /src/<subdir>/..."
But this kind of deduction do not seem to work for every case (you know in adavance module X is in repo Y and try to see if you can find it and define its content by some rule)