Re: [Development] Sub-arch optimisations (was: How qAsConst and qExchange lead to qNN)
On Sunday, 20 November 2022 18:38:08 PST Thiago Macieira wrote: > I've just finished a qtbase build on Linux with two sub-architectures and > the symbol comparison of all the resulting libraries has shown zero > difference.. Done. All modules now built in multi-subarch mode. I've submitted a few cleanup commits to the modules to fix issues that don't depend on the new functionality. My script is showing symbol differences between the two builds. It looks like all the qml_register_types_* symbols are missing and half of QtLocation. I'll need to investigate tomorrow. Meanwhile, I've also completed the first part of the macOS switch to v3: https://codereview.qt-project.org/c/qt/qtbase/+/444538 Tested locally and the build is ok. I'll add the QT_BUILD_ARCH support to it when I'm finished on Linux. > [*] I had an idea an hour ago, thinking about the qxcb plugin and remembered > the old KDE Brockenbores solution. Didn't work so well. It's possible to link to an executable, but requires removing one bit from the dynamic section. I managed it, but it's probably not worth the hassle: $ ls -l libexec/moc -rwxr-xr-x 1 tjmaciei users 2592 Nov 21 18:48 libexec/moc $ ldd libexec/moc | sed 's/(.*//' linux-vdso.so.1 moc.so => /home/tjmaciei/obj/qt/qt6/qtbase/libexec/binlib/haswell/moc.so libpcre2-16.so.0 => /lib64/libpcre2-16.so.0 libstdc++.so.6 => /lib64/libstdc++.so.6 libm.so.6 => /lib64/libm.so.6 libgcc_s.so.1 => /lib64/libgcc_s.so.1 libc.so.6 => /lib64/libc.so.6 /lib64/ld-linux-x86-64.so.2 $ libexec/moc --version moc 6.5.0 $ libexec/binlib/haswell/moc.so --version moc.so 6.5.0 -- 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
Re: [Development] Renaming quint128
On Monday, 21 November 2022 02:52:10 PST Ivan Solovev via Development wrote: > > https://codereview.qt-project.org/c/qt/qtbase/+/444237 > > https://codereview.qt-project.org/c/qt/qtbase/+/444238 > https://codereview.qt-project.org/c/qt/qtbase/+/444239 > > I can only access the first patch. The other two links show "Not found". My bad, the last two should be '58 and '59. I did the lazy trick of pasting the same URL three times and updating the last digit, but didn't notice that they were off by 20. -- 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
Re: [Development] Renaming quint128
Thiago shared: >> https://codereview.qt-project.org/c/qt/qtbase/+/444237 >> https://codereview.qt-project.org/c/qt/qtbase/+/444238 >> https://codereview.qt-project.org/c/qt/qtbase/+/444239 Ivan Solovev (21 November 2022 11:52) replied: > I can only access the first patch. The other two links show "Not found". I had a similar problem, but if you go to the first link the other two are the next two in its relation chain. Not sure why the pasted URLs fail, but you can bypass the need for them, Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Renaming quint128
Hi Thiago, > Now at https://codereview.qt-project.org/c/qt/qtbase/+/444222 Thanks for sharing it! > In fact, I came up with a better solution yesterday after sending this email: move the support to QUuid. This allows us to have the new (mostly) source- compatible API in place and simply move the existing QBluetoothUuid content to removed_api.cpp. This sounds like a good approach, but unfortunately it does not cover all usecases for quint128 in QtBluetooth. See, for example, struct SigningData in qlowenergycontroller_bluez_p.h (https://code.qt.io/cgit/qt/qtconnectivity.git/tree/src/bluetooth/qlowenergycontroller_bluez_p.h#n152) or class LeCmacCalculator (https://code.qt.io/cgit/qt/qtconnectivity.git/tree/src/bluetooth/lecmaccalculator_p.h#n23) I'm not very familiar with the code but, AFAICT, these examples have nothing to do with QUuid. However, they all are private, so we might just want to introduce a new private struct which will behave similarly to the current "struct quint128", and that should fix the issues with private APIs. > I'll wait for 6.6. Good to know, thanks. > https://codereview.qt-project.org/c/qt/qtbase/+/444237 https://codereview.qt-project.org/c/qt/qtbase/+/444238 https://codereview.qt-project.org/c/qt/qtbase/+/444239 I can only access the first patch. The other two links show "Not found". Best regards, Ivan From: Development on behalf of Thiago Macieira Sent: Friday, November 18, 2022 10:07 PM To: development@qt-project.org Subject: Re: [Development] Renaming quint128 On Friday, 18 November 2022 09:05:51 PST Thiago Macieira wrote: > In fact, I came up with a better solution yesterday after sending this > email: move the support to QUuid. This allows us to have the new (mostly) > source- compatible API in place and simply move the existing QBluetoothUuid > content to removed_api.cpp. https://codereview.qt-project.org/c/qt/qtbase/+/444237 https://codereview.qt-project.org/c/qt/qtbase/+/444238 https://codereview.qt-project.org/c/qt/qtbase/+/444239 -- 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 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
