[hereisdx]

In fact,from Qt 5.15 onwards the offline installer is provided only for commercial license holders.

Say goodbye to: - Installing on multiple PCs at once - Installing on PCs without internet connections.

It's also possible that the online installer collects telemetry data.

[Rochus]

So why don't we start providing Qt binary version installers ourselves? Most Linux distros already do it, so we can focus on Windows and MacOS. Maybe some subdomain of kde.org?

[edsac_xyzw]

The trouble of distributing Qt in binary format is the C++ non standard ABI problem. Qt has to be compiled for every possible compiler and many different versions of the same compiler, in order to avoid linking error. On Unices, most compilers, specially GCC and Clang, are using the Itanium ABI, but on Windows, compilers still have different ABIs, so linking against Qt shared libraries built with older versions of MSVC compiler may result in linking error. On Linux, there still the problem of implicit dependency on GlibC (GNU C Library), most applications built using newer versions of GlibC will not work on distributions using older versions of GlibC. It would be nice for Linux Desktop, if GlibC did not break the binary compatibility.

That said, the most suitable way to get Qt binaries for development may be using a C++ package manager such as Conan or Vcpkg which can cache the library compilation output and reuse it on many different projects without recompilation, unless the current compiler has an incompatible ABI.

Conan C++ package manager recipes can also provide pre-compiled binaries which reduces the compile time pain. Another interesting tool is the conan server which allow fetching conan recipes and pre-compiled binaries on the local network or across the internet.

[Rochus]

In practice there are not so many. And e.g. on Windows I use an old VS compiler version and can then also use it with later VS versions (but not vice versa). Linux is also no issue because Qt is usually part of the distribution, i.e. there is no need to compile it as long as you depend on the standard version (not a custom one).

Personally I don't work with package managers, but prefer so setup and control the environment myself. It's not that difficult, and there is also Docker.

[edsac_xyzw]

On Windows, MSVC does not provide guarantees that it will not keep the ABI on new releases. The drawback of using the Qt provided by the Linux distribution, is the reproducibility of the development environment as it is not possible to control the version of the Qt installed and also to have multiple Qt installations with different versions. As a result, the compilation of a Qt application may fail on different Linux distribution which uses a different and incompatible version of Qt. Docker can solve the reproduciblity of the development environment problem, but it still does not integrate well with development tools such as IDEs, building systems and so on.

The advantage of a package manager is the reuse of binary artifact on many projects and also the control over the library version. Conan package manager could be used for providing pre-compiled binary artifacts of Qt library. For instance, provides pre-compiled boost library and poco library for lots of different compilers, compiler versions and operating systems which saves one from building and installing those libraries.

[the_why_of_y]

> It would be nice for Linux Desktop, if GlibC did not break the binary compatibility.

Then it's good that it doesn't do that.

[shakna]

The sources will only be updated once every twelve months, to account for this.

[Rochus]

Are you sure? Where did you read that?

[shakna]

Here it is from the KDE discussion [0], and from Qt themselves [1].

> But last week, the company suddenly informed both the KDE e.V. board and the KDE Free QT Foundation that the economic outlook caused by the Corona virus puts more pressure on them to increase short-term revenue. As a result, they are thinking about restricting ALL Qt releases to paid license holders for the first 12 months. They are aware that this would mean the end of contributions via Open Governance in practice. [0]

> Starting with Qt 5.15, long term support (LTS) will only be available to commercial customers. This means open-source users will receive patch-level releases of 5.15 until the next minor release will become available. [1]

[0] https://mail.kde.org/pipermail/kde-community/2020q2/006098.h...

[1] https://www.qt.io/blog/qt-offering-changes-2020

[Rochus]

Thanks, but only the "LTS for paying customers only" is decided. The other statement was just an idea which wasn't implemented, as far as I know.

[shakna]

It's on Qt's announcement page. That's a pretty definitive statement.

[PunksATawnyFill]

Was wondering the same thing, and downloaded the source to experiment. I’m on Mac.

What do you think it would take?

[Rochus]

It's not that difficult. I would recommend to use not the most recent OS and compiler version, otherwise you risk that only users having your or a later OS/compiler version can use it.

[xenonite]

Well, I am anyways stuck with Qt 5.11, which is the last version that runs on macOS 10.11.

[PunksATawnyFill]

EXACTLY. I called them out on this bullshit the other day, and they tried to sell me a “small business” commercial license or something.

FORK YOU, Qt Company!