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 <development-boun...@qt-project.org> 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
