I’ve been helping a developer building Slicer on Windows, and I’m shocked to see what The Qt Company did again: they removed Qt-5.15 binaries from their servers. Qt5 versions more recent than Qt-5.12 are no longer available as binary packages.
Our options seem to be:
A. Recommend developers to use Qt-5.12: Not a great solution, as all the bugs that have been fixed since Qt-5.12 would return.
B. Build latest Qt5 version from source. Difficulty is that Qt easy-build has not been updated recently for Windows (as we did not expect the Qt Company to retrospectively remove Qt versions that it provided earlier).
C. Expedited upgrade to Qt6: It would not be an easy task, as we need to upgrade CTK and PythonQt and then Slicer to support Qt6.
D. Pay for Qt: This could be reasonable if the The Qt Company would set a reasonable price for their services and they would not be so hostile tp open-source developers.
Have you run into this issue recently? How did you solve this issue?
I’ve checked again on a different computer, using the Qt online installer to install Qt from scratch and this time Qt5 binary packages up to Qt-5.15.2 were available for installation again. It might have been a glitch in the file hosting server yesterday or something wrong in that computer’s configuration. Anyway, this is no longer an emergency.
Still, this short scare showed how exposed we are to Qt changes. We could reduce our vulnerability by making Qt easy-build work again for Windows, but probably a more forward-looking solution would be to increase priority of switching to Qt6.
I agree, this is an odd situation. I personally think that the Qt company is hurting themselves by discouraging open source developer participation. If developers don’t know Qt then companies will have no reason to use it in products.
For now, I think the best options are to migrate more quickly to Qt 6, which is something we want to do anyway, and work on getting qt-easy-build working (ideally for Qt 5 and 6).
What you originally described seemed like an issue of an outdated Qt Maintenance Tool as though it was too old and didn’t know yet of Qt 5.15.
+1 here. The qt-easy-build makes sense for the non-cmake build process of Qt5, but since Qt6 is cmake-ified natively it would seemingly just slot into the superbuild process if not using binaries.
Below is an open PR of mine that is working towards Qt6 support by replacing the deprecated Qt Script dependency.
Likely just not selecting the LTS/Archive categories to filter. The tool by default only shows latest supported versions and also already installed versions.
Thanks for starting the topic Andras. I think I have seen such a glitch before but in a few minutes the package was available again so I probably thought it was a network issue. I agree with trying to prioritize the switch to Qt6.
Do we know how much Qt would cost for a platform like Slicer? As far as I know you can purchase licenses per developer (may be mistaken or may have changed), which model does not fit our case well.
I’ve never seen that the Qt company would have a purchase option that would make sense for Slicer. We are very careful to stick with their LGPL requirements so it would be hard to justify spending money on any such option even if they had it. As long as we are able to support our current use cases with the LGPL option I think we are in a good spot, and keeping up with their latest versions isn’t a bad idea so long as it doesn’t break something we really need.
I’m intrigued that the new CMake support in Qt could make it easier for us to integrate with Slicer’s superbuild. Even if you usually would want to build against a binary package for efficiency having the build from source option would be great.
