ppisa
commented
1 month ago I would add my two cents. For Qt development, I often consult Frantisek Vacek and his team from https://www.elektroline.cz/ . He, personally, is long term expert on Qt, he started his orienteering software and other project to rewrite on Qt from Borland C++ Builder at time of Qt2 or may it be Qt1. Has been one of the first developers paying for commercial version and has attended multiple Qt conferences and even disused with core developers. He has stated that qmake is dead when there has started planning of Qt6 release. Same is meaning of other people around him even with different background. So I expect that qmake is maintained only for backward compatibility. Even Qt themselves are built by CMake https://doc.qt.io/qt-6/qt6-buildsystem.html . qmake support is limited in Qt 6. For example plugins has to be ported to CMake, qmake is no longer supported. It is highly probable that Qt 7 do not support qmake at all.
qmake will still be supported in Qt 6 for user apps. But in Qt 7 it is likely to be completely dropped.
QtRvSim has qmake packaging for Debian but it has not been complete to build proper DSC files. That part can be copied only from versions after CMake switch.
Hello,
this issue is basically a question: would you be open towards switching the build system from Qt's
qmaketo standard CMake?:heavy_plus_sign: It would allow some of the build and packaging logic for Windows/Linux/macOS to be shared with e.g. QtRvSim. :heavy_plus_sign: It should be more slightly more future-proof (Qt5 & Qt6 still support qmake, but eventual future versions are not that clear - see reddit). :heavy_minus_sign: It might require changes to your Windows build environment. I think doing this with Qt 5.6.3 should be possible, but I have not tested it yet. Alternatively, the Windows build could be done on GitHub via GitHub Actions, but I can imagine that this could complicate local development/testing.
Thank you
Jakub Vaněk