Hello all A few of us have just had a call to discuss what we're going to do for the functionality I proposed for 6.5. Here are our conclusions and proposals.
First, we're going to postpone this to 6.6, on account of feature freeze being too close. While I think the risk is minimal for non-Linux architectures, I might have broken things I don't know about. And there's also a risk for Linux where we accidentally and silently mis-compile something and it only fails at runtime. So this requires more eyes and more time. Second, the code I developed is ugly. And it's fragile, leading to the potential issues mentioned above. Instead, Alexandru had a different idea on how to do this, which matches what we're doing for the Android Multi-ABI support, which could then be extended to the macOS universal builds. Details on this on a separate email. But we'd like to try this alternate solution instead and see if it is more resilient than what I did. For this alone, we need more time. Third, there's the question of compile time and whether it's worth the cost for all libraries (cost in time to build as well as installed size). I did this for every single Qt module library, but my intention was to add an option so a few libraries' CMakeLists.txt files could opt in, leaving it disabled for everything else, which further reduces the risk by reducing the problem surface. To make a choice, we'll need a metric, to be determined. My guesstimate is that it will be worth for our three traditional core libraries (QtCore, QtGui, QtWidget), the two Qml core libraries (QtQml and QtQuick), and the Qt3D Core and Render libraries. It's not a coincidence that the five biggest libraries of our own code are also the first five I listed here; maybe #7 (QtQuick3DPhysics) could be there too. Fourth, there's the Qt3D qmake code. I was surprised to find out that qt3d 6.x module was meant to compile with Qt 5's qmake. This is not tested in our CI, I believe. I don't think any Linux distributions know about this, either. So who's using it? We need a decision going forward whether this support shall remain, in particular as Qt 6.5 should be a Commercial LTS, so 6.6 is a good point for dropping some compatibility. Jörg, Tor Arne, Alexandru, Kai, Alexey, anything I forgot? -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
