force applicationDirPath into first position when finding plugins
AbandonedPublic

Authored by sitter on Thu, Aug 22, 1:22 PM.

Details

Reviewers
mpyne
dfaure
Summary

applicationDirPath technically is already part of libraryPaths BUT it's
position isn't specified and as it turns out is in fact last and not first.
this has the unfortunate side effect that when trying to test a KIO
slave from the cmake build directory it would not get loaded unless it
isn't available in the system path.

to ensure slaves are loaded preferably relative to the applicationDirPath
we'll force-prepend the path to applicationDirPath

Test Plan

running bin/http_jobtest of kio correctly loads the slave from the build dir

QDEBUG : HTTPJobTest::testBasicGet() http_jobtest(2381)/(org.kde.kcoreaddons) ?[31m?[34mKPluginLoader::forEachPlugin?[0m: Checking for plugins in ("/home/me/src/git/kio/build/bin/kf5/kio", "/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio", "/home/me/src/git/kio/build/bin/kf5/kio")

Diff Detail

Repository
R244 KCoreAddons
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 15468
Build 15486: arc lint + arc unit
sitter created this revision.Thu, Aug 22, 1:22 PM
Restricted Application added a project: Frameworks. · View Herald TranscriptThu, Aug 22, 1:22 PM
Restricted Application added a subscriber: kde-frameworks-devel. · View Herald Transcript
sitter requested review of this revision.Thu, Aug 22, 1:22 PM

Hmm, I don't think this is a good thing to do.

e.g. look at this setup:

You have some globally installed Kate/KDevelop/...

You develop a plugin, it is already shipped with the global install by the distro.
You compile locally your plugin and setup the QT_PLUGIN_PATH correctly.

At the moment, your new plugin will be used.
With this change, always the pre-installed global one will be prefered, or?

sitter abandoned this revision.Thu, Aug 22, 2:01 PM

Agh, you are very right of course. Things are never easy :/

Yes, I have some review request that does something similar inside Kate and I am not sure that this would help us either.

https://invent.kde.org/kde/kate/merge_requests/8

Perhaps the answer actually is that QT_PLUGIN_PATH should not be necessary ;)

This is a bit of a chicken and egg problem. When our software can't find plugins automatically we resort to QT_PLUGIN_PATH, but then because we use QT_PLUGIN_PATH we can't just break it to make our software smart. Perhaps the way to go about it is to manually build a list similar to libraryPaths, the idea makes me shiver though... or... just have the libraryPaths order changed in qt. I am really not sure there is a case where plugins "next to" the binary wouldn't be preferred over the ones in lib directories.

;=) Yeah, all ugly.
Even with the above code btw. an uninstalled Kate would still not find the plugins as it wants them in some "ktexteditor" subdir in plugins but with the current CMake setup they will end in the build directory in directly the same dir as the application executable.

That is a solvable problem, there's a property to control where things end up in the build tree:
set_target_properties(kio_ftp PROPERTIES LIBRARY_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/bin/kf5/kio")