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.
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.
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.
Then it's good that it doesn't do that.
> 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...
What do you think it would take?