Add all required plugin paths in QCoreApplication, instead of relying on environment variable
Review Request #127288 - Created March 5, 2016 and discarded
For some reason, an emerge build will install Qt plugins not in just one, but in three separate directories (KDEROOT/plugins, KDEROOT/lib/plugins, KDEROOT/plugin). I have not investigated why this is the case, or how that could be changed. However, I assume that may not be trivial.
To make applications work in that setup, Qt needs to be informed of the plugin paths. Since qt.conf supports only a single path, that cannot be used, for this. Rather, emerge sets the QT_PLUGIN_PATH environment variable. While this works, it also makes it difficult to deploy any application. In fact, currently, a MinGW compiled, NSIS-packaged app will not run at all, because Qt can't find the windows platform plugin. (I do seem to remember, but have not tried, again, that an MSVC-compiled application was not affected by this, for some reason). Copying the platform-plugin to KDEROOT/bin would work around this, but Qt would still not find any other plugin, then.
Clearly, installers could be adjusted to set QT_PLUGIN_PATH on the target system. However, this could interfere badly with parallel installations of Qt/KF5, and it would prevent nice-to-have features such as being able to move an installed KF5 application to a different path (e.g. on a thumb drive), or in fact moving an entire emerge tree.
Long story short, the only way I can see to support all required plugin paths without the need for QT_PLUGIN_PATH, is to patch them into QCoreApplication, which is what this diff does. After a certain grace-period, it would also make sense to remove the corresponding init code from EmergeSetupHelper.py.
- Built qtbase from scratch on MinGW.
- Packaged RKWard and deployed it on a separate system, successfully.
- Also deployed kate, and verified that it can find its plugins.
- Renamed KDEROOT and started applications in it, successfully, too.
Note that I tested with qt 5.5, only. Importantly, I did not test with 5.6 (or 5.4), altough emerge will (try to?) apply the patch, there, too.
I don't think that patching Qt instead fixing the reaons is a valid solution here.
I think most of the problems consist because -DKDE_INSTALL_USE_QT_SYS_PATHS=TRUE is not passed to cmake when building the applications. See also https://git.reviewboard.kde.org/r/127169/ for a possible solution which does not require passing KDE_INSTALL_USE_QT_SYS_PATHS to cmake anymore in the future
Also see https://github.com/KDE/emerge/blob/master/portage/extragear/kdevelop/kdevelop.py#L79 for a fixup during packaging time in emerge.
I knew -DKDE_INSTALL_USE_QT_SYS_PATHS=TRUE before, but we didn't bother enough to set this by default in emerge now. Also, https://git.reviewboard.kde.org/r/127169/ indeed seems to be the saner approach.