> On March 5, 2016, 4:04 p.m., Christian Ehrlicher wrote: > > 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
Ah, good to know a (clean) fix is under way. - Thomas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127288/#review93202 ----------------------------------------------------------- On March 5, 2016, 2:50 p.m., Thomas Friedrichsmeier wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127288/ > ----------------------------------------------------------- > > (Updated March 5, 2016, 2:50 p.m.) > > > Review request for kdewin. > > > Repository: emerge > > > Description > ------- > > 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. > > > Diffs > ----- > > portage/libs/qt5/qtbase/qtbase-pluginpaths.py PRE-CREATION > portage/libs/qt5/qtbase/qtbase.py 3331952 > > Diff: https://git.reviewboard.kde.org/r/127288/diff/ > > > Testing > ------- > > - 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. > > > Thanks, > > Thomas Friedrichsmeier > >
_______________________________________________ Kde-windows mailing list Kde-windows@kde.org https://mail.kde.org/mailman/listinfo/kde-windows
