As I understand it, the problem is that plugins installed to PREFIX/lib/qt/plugins won't always be be found depending on PREFIX.
It will work for "/usr" and probably "/usr/local" (can you confirm the latter, Martin? I didn't test it).
But if I install e.g. to a directory in the Krusader source directory (a quick local installation for testing) the plugins won't work. And this will may be left unnoticed by the user.

Adding a warning in this case would be good - with a hint that -DQT_PLUGIN_INSTALL_DIR should be used. But my knowledge about CMake is limited.
Besides that I'm fine with removing these lines.

@asensi Can you comment, please? Because you added this

Because you added this

Thanks for mentioning it, the change was caused because QT_PLUGIN_INSTALL_DIR became deprecated, etc. There was more information in:

https://phabricator.kde.org/T2115
https://phabricator.kde.org/D1323

Thanks for the lot of good info!

"/usr" and probably "/usr/local" can you confirm the latter, Martin?

I've tested /usr/local and it works as well on Arch. Although if one use a different CMAKE_INSTALL_PREFIX, the plugins fail to load, like You said, Alex.

It probably has also something to do with the location where KDE libraries are installed. Because if I run the whole plasma session with ~/kde/usr prefix (default for ./kdesrc-build), I can use krusader within this prefix along with its plugins. Meaning without the KDE_INSTALL_USE_QT_SYS_PATHS flag.

I've seen the various links and info in T2115. Interesting is this e.g. change:
https://git.reviewboard.kde.org/r/127169/

• Qt plugin directory is by default united with cmake one, which is probably fixing the mentioned Ubuntu problems
• Also here they say KDE_INSTALL_USE_QT_SYS_PATHS ... This variable should NOT be set from within CMakeLists.txt files, instead is intended to be set manually when configuring a project which uses KDEInstallDirs (e.g. by packagers).

Therefore I still believe we should remove it. But I agree we should add a warning as a hint for users. I'll update the diff. But I'm of course still open for other suggestions including letting it be :).

Hi! I tried the patch, using Kubuntu 17.10, and everything seems to work correctly.

One interesting thing to note is that prior to applying this patch: after a cmake [...]; make && sudo make install Krusader was installed in /usr/local/bin/, but after applying this patch: Krusader is installed in /usr/bin/

-Thanks, Toni, for trying it out! :-) I believe that cmake is installing into /user/local by default no matter KDE_INSTALL_USE_QT_SYS_PATHS is set or not. At least on Arch Linux it works out like that. Only after setting -DCMAKE_INSTALL_PREFIX=... the install prefix get changed. And that is persisted even if next cmake call is performed without this switch. Best practice for me is cleaning up build folder before calling cmake to have a predictable results. Again, it works like that in Arch Linux with cmake version 3.10.2, I'm not sure if other distributions behave the same.

Anyway this does not probably matter so much at this point. Thanks for the testing. I'll wait for a while and if there aren't any further objections I'll push the change.

Thank you both for informative answers!

@asensi Toni, thanks for clearing up the commands you used. I've used almost the same, just not with the C/CXX flags. So there have to be differences in distributions.

@nmel Nikita, good point with the layout.xml. There we will probably have to change the way it is installed and loaded in a way that we either force loading the installed one, or we primarily try to load the one in .local/share and as a "fallback" we load the installed one. But I can be wrong about this approach. I also cannot simulate when the .local/share/krusader/layout.xml is being created.