Qt 5.15.7 bump

[a17r]

Will be pushed to Gentoo ebuild repo. Some patchset respins are expected to come before that.

Currently leads to the following build errors on my system:
qtgui: https://invent.kde.org/-/snippets/2338/raw/master/qtgui-5.15.6.build.log
qtwidgets https://invent.kde.org/-/snippets/2340/raw/master/qtwidgets-5.15.6.build.log

Identified commit 2dc083d, but no idea why. See also https://invent.kde.org/qt/qt/qtbase/-/merge_requests/197

Okay, for some reason builds fine when I remove #if QT_CONFIG(dbus) from src/platformsupport/services/genericunix/qgenericunixservices.cpp.

[jospezial]

Currently leads to the following build errors on my system

Confirming dev-qt/qtgui-5.15.6.9999:5/5.15.6::qt, ran into the same.

Btw, if you look for that file in qtgui dev branch, it was moved to
src/gui/platform/unix/qgenericunixservices.cpp

[a17r]

It is as if Qt5 is built without dbus support. Revdeps fail too. Something is changed in the build system, no idea what.

[Pesa]

@a17r @jospezial I'm trying to debug the dbus issue, could either of you please post global/qconfig.h and global/qconfig_p.h installed on their system after qtdbus is emerged? (the latter might be in the private header dir)

[a17r]

a lot of debugging has already happened by @Arfrever maybe they can chime in

let's try to get you on the same page via irc backlog (some progress was made already): https://gist.githubusercontent.com/a17r/c4f33fe6b04e320e229e69d87f4764a2/raw/cb4af0f6c09a642bb194ca1dfbd6087334243063/%2523g-qt-back.log

[a17r]

@Pesa here are both files coming from a fully installed Qt: https://gist.github.com/a17r/e307ed1e0d4dc3511f58fd6b5b150896

Unless you meant something different, but I wasn't able to do any more experiments today anyway.

[Pesa]

let's try to get you on the same page via irc backlog (some progress was made already): https://gist.githubusercontent.com/a17r/c4f33fe6b04e320e229e69d87f4764a2/raw/cb4af0f6c09a642bb194ca1dfbd6087334243063/%2523g-qt-back.log

Thanks. The first half of that discussion confirms what I found/suspected: this is the result of that major build system refactoring that upstream did a few years ago (around 5.8 maybe?) and that I keep blaming for most of our weird build-related issues. The problem is that we never properly adapted our packaging/eclass to those upstream changes, and we've been paying the price ever since, adding more and more hacks and bandaids.

What @Arfrever doesn't know is that all the logic in qt5_install_module_config was never supposed to handle the QT_FEATURE_* stuff... that started appearing upstream much later. qt5_install_module_config was designed to handle the QT_NO_* macros only (and other stuff in .pri files). I'm not sure if upstream treats/uses QT_FEATURE_* and QT_NO_* differently, or if the former is just the new/modern way of accomplishing the same goal.

qt5_install_module_config also doesn't handle the "split" (per-module) qt${mod}-config.h and qt${mod}-config_p.h files, simply because they didn't exist (or weren't relevant) when the eclass was written. This has probably caused other bugs in the past, but it doesn't affect the current dbus issue because the dbus feature flag goes in the global qconfig_p.h. I'm mentioning this for completeness, just in case someone wants to rewrite this part of the eclass.

Finally, the "undocumented misfeature of QT5_GENTOO_CONFIG" mentioned by @Arfrever is in fact by design, and I was relying on that behavior in several ebuilds. I don't know if current ebuilds still use that feature. But if you plan to change it, be careful.

[Pesa]

What @Arfrever doesn't know is that all the logic in qt5_install_module_config was never supposed to handle the QT_FEATURE_* stuff... that started appearing upstream much later. qt5_install_module_config was designed to handle the QT_NO_* macros only (and other stuff in .pri files). I'm not sure if upstream treats/uses QT_FEATURE_* and QT_NO_* differently, or if the former is just the new/modern way of accomplishing the same goal.

What I'm trying to say here is that retrofitting QT_FEATURE_* to qt5_install_module_config might not be the best course of action. QT_FEATURE_foo behaves substantially different from the QT_FOO and QT_NO_FOO pair of macros. For instance:

• There is no QT_NO_FEATURE_foo. Instead, QT_FEATURE_foo is defined to -1 to indicate that the feature is disabled.
• The #ifdef...#undef logic of qconfig.h cannot be applied to the FEATURE macros, because if QT_FEATURE_foo is undefined at the point where QT_CONFIG(foo) is used, compilation will fail.

[Arfrever]

What @Arfrever doesn't know is that all the logic in qt5_install_module_config was never supposed to handle the QT_FEATURE_* stuff... that started appearing upstream much later. qt5_install_module_config was designed to handle the QT_NO_* macros only (and other stuff in .pri files). I'm not sure if upstream treats/uses QT_FEATURE_* and QT_NO_* differently, or if the former is just the new/modern way of accomplishing the same goal.

What I'm trying to say here is that retrofitting QT_FEATURE_* to qt5_install_module_config might not be the best course of action. QT_FEATURE_foo behaves substantially different from the QT_FOO and QT_NO_FOO pair of macros. For instance:

* There is no `QT_NO_FEATURE_foo`. Instead, `QT_FEATURE_foo` is defined to `-1` to indicate that the feature is disabled.

We are aware of their different behavior, and this is why my aforementioned patch for qt5-build.eclass contains this fragment:

                if [[ -z ${flag} ]] || { [[ ${flag} != '!' ]] && use ${flag}; }; then
                        [[ -n ${feature} ]] && qconfig_add+=" ${feature}"
-                       [[ -n ${macro} ]] && echo "#define QT_${macro}" >> "${T}"/${PN}-qconfig.h
+                       if [[ -n ${macro} ]]; then
+                               if [[ ${macro} == FEATURE_* ]]; then
+                                       echo "#define QT_${macro} 1" >> "${T}"/${PN}-qconfig.h
+                               else
+                                       echo "#define QT_${macro}" >> "${T}"/${PN}-qconfig.h
+                               fi
+                       fi
                else
                        [[ -n ${feature} ]] && qconfig_remove+=" ${feature}"
-                       [[ -n ${macro} ]] && echo "#define QT_NO_${macro}" >> "${T}"/${PN}-qconfig.h
+                       if [[ -n ${macro} ]]; then
+                               if [[ ${macro} == FEATURE_* ]]; then
+                                       echo "#define QT_${macro} -1" >> "${T}"/${PN}-qconfig.h
+                               else
+                                       echo "#define QT_NO_${macro}" >> "${T}"/${PN}-qconfig.h
+                               fi
+                       fi
                fi

* The `#ifdef`...`#undef` logic of `qconfig.h` cannot be applied to the FEATURE macros, because if `QT_FEATURE_foo` is undefined at the point where `QT_CONFIG(foo)` is used, compilation will fail.

The problem which actually happens is not that some QT_FEATURE_* are undefined, but that they are defined with wrong values (-1 instead of 1).

[Arfrever]

The last part of explanation in IRC was:

[2022-09-10 21:23:06 UTC] <[Arfrever]> Anyway I can already guess cause of problem.
[2022-09-10 21:24:45 UTC] <[Arfrever]> QtCore/qconfig.h is installed by qtcore, and is patched to start with: #include <Gentoo/gentoo-qconfig.h>
[2022-09-10 21:25:05 UTC] <+asturm> [Arfrever]: https://gist.githubusercontent.com/a17r/c4f33fe6b04e320e229e69d87f4764a2/raw/2c62de3fbdd3d42e80773e4725859f954c1ebbfc/workdir_qconfig.h
[2022-09-10 21:25:10 UTC] <[Arfrever]> Lines 289-292: https://gitweb.gentoo.org/proj/qt.git/tree/eclass/qt5-build.eclass?id=56064249c35a88e07c8ef642d61e767877e0ee98#n269
[2022-09-10 21:25:45 UTC] <+asturm> anyway, I've gotta go now, it's late and we'll get visitors tomorrow
[2022-09-10 21:26:20 UTC] -!- asturm [~andreas@gentoo/developer/asturm] has quit [Quit: Konversation terminated!]
[2022-09-10 21:27:47 UTC] <[Arfrever]> In build log, at least for qgenericunixservices.cpp, options are in this order:
[2022-09-10 21:28:32 UTC] <[Arfrever]> ... -I/var/tmp/portage/dev-qt/qtgui-5.15.6/work/qtbase-everywhere-src-5.15.6/include ... -I/usr/include/qt5/QtCore/5.15.6 -I/usr/include/qt5/QtCore/5.15.6/QtCore -I/usr/include/qt5 -I/usr/include/qt5/QtDBus -I/usr/include/qt5/QtCore ...
[2022-09-10 21:30:02 UTC] <[Arfrever]> So /usr/include/qt5/QtCore/qconfig.h (which is modified to have '#include <Gentoo/gentoo-qconfig.h>') is not used, but ${S}/include/QtCore/qconfig.h is used :( .
[2022-09-10 21:33:10 UTC] <[Arfrever]> This 'sed' command will have to be moved to: https://gitweb.gentoo.org/proj/qt.git/tree/eclass/qt5-build.eclass?id=56064249c35a88e07c8ef642d61e767877e0ee98#n667

[a17r]

@AndrewAmmerlaan @waebbl ^ just in case you want to prepare dev-python/pyside2...

[waebbl]

Thanks @a17r for this hint. Not sure, if I will be able to look at it this week. Next week I'm on vacation and can't work on this, but I keep an eye on it and re-check on weekend of next week.

[Arfrever]

The last part of explanation in IRC was:
...

Description of situation was correct, but that idea of fix would have no effect.

[a17r]

@Pesa @Arfrever 5.15.7 moved to tree with workaround, discussion tbc in #261