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
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")| No Linters Available |
| No Unit Test Coverage |
| Buildable 15468 | |
| Build 15486: arc lint + arc unit |
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?
Yes, I have some review request that does something similar inside Kate and I am not sure that this would help us either.
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")