Hi Giuseppe,
I agree that the current situation is somewhat complicated. But the approach
piloted at https://www.qt.io/blog/qt-6-additional-libraries-via-package-manager
hopefully will help to tell a more aligned story in the future, at the price of
(temporarily) adding yet another way of getting libraries (add mandatory xkcb
link here).
Let me explain where we're coming from, and why the new approach will hopefully
allow the Qt ecosystem to grow, and also allow for more flexible setups than
it's traditionally possible with our online installer setup.
The primary channel we have for distributing Qt to our users is currently the
online installer. It provides always the latest Qt packages, prebuilt for the
most common platforms/compilers. Anyhow, it's clear by now that this approach
of providing binary packages built by The Qt Company has its limits. Just from
the effort side (both human and CI), we cannot endlessly add packages to a
'monolithic' Qt release, and still expect to make releases on time. Also,
because a lot of modules also use internal API, it's hard to support packages
that are released independently of the main Qt, or do support different Qt
versions in one package. This all puts a limit on the growth and flexibility of
what typical users (without additional effort) can get as 'Qt' in the online
installer.
So for some of the packages, we decided it's easier to distribute them as
source only. Anyhow, it's not convenient to find, use, and build these,
especially if you're used to just use the online installer.
With the approach in
https://www.qt.io/blog/qt-6-additional-libraries-via-package-manager we want to
overcome some of these limitations, bringing the online installer and source
packages closer together. Qt users will get additional libraries through the
online installer. But instead of a pre-built package, they get a Conan recipe
that allows them to build things locally, in their specific environment for
their selected Qt version.
If this approach works out, we should arguably leverage it for many more Qt
Addons. Anyhow, we're arguably very late in the game for 6.0, so the aim is to
pilot it with some modules first.
Hope this explains the big picture a bit.
Regards
Kai
> -Ursprüngliche Nachricht-
> Von: Development Im Auftrag von
> Giuseppe D'Angelo via Development
> Gesendet: Freitag, 30. Oktober 2020 12:35
> An: development@qt-project.org
> Betreff: [Development] Installer/Marketplace/Package Manager
>
> Hi,
>
> referring to
>
> > https://www.qt.io/blog/qt-6-additional-libraries-via-package-manager
>
> it looks like that the situation regarding Qt binary packaging and
> distribution
> around the time 6.0 will be shipped will look like this:
>
>
> 1) Binary (*) Qt Essentials from the installer, OSS+Comm
> - QtCore, QtWidgets, QtQML, etc.
>
> 2) Binary (*) Qt Addons from the installer, OSS+Comm
> - QtSQL, QtQuick3D, etc.
>
> 3) Binary (*) extras from the installer, OSS+Comm
> - QtCreator, MinGW, OpenSSL, CMake, etc.
>
> 4) Source and/or binary Qt Addons from the Marketplace, OSS+Comm
> - QtPDF, QtCharts, etc.
>
> 4a) Non-software products from the Marketplace
> - E.g. TQC Trainings
>
> 5) Source Qt Addons from the Package Manager, OSS(+Comm?)
> - Qt3D, QtImageFormats
> - to be built manually
>
>
> (*) One can install the source, but they're for debugging, one doesn't
> build them
>
> Am I getting the complete picture? And am I the only one who finds this
> extremely confusing? How is the decision regarding what-goes-where made?
>
>
> Thanks,
>
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
