On 2019.01.14 14:37, Ralf Habacker wrote:
Am 14.01.19 um 20:31 schrieb Jack:
>> The patch from https://phabricator.kde.org/D16764 should help.
Thanks Ralph, and I'll give it a try, but I had thought an IDE
(QT-Creator in this case) would know where things are, since it
insists on compiling the whole project before starting to debug it.
This is true for shared libraries, but kcoreaddons does not know from
which directory to load the plugins, which is provided by the patch.
And kmymoney5 could not load anything without plugins.
Once I solve the basic problem of getting QT to load the newly compiled
plugins instead of the system installed ones, I'll go back to whether
this can be done in QT-Creator by creating an appropriate build/run
configuration, but for now, I can't even get the basics right.
Ralf
I admit I have not actually applied the patch, but it seems the real
critical parts are the new instructions in Quick-start 5 to run from
the build directory. I'm running on Linux, and I can see that things
get compiled and installed as expected.
I've been trying all sorts of variations, but going back to the most
straightforward:
My build directory is parallel to the source, not under it. This
should be fine, shouldn't it?
I'm using ninja instead of make, so one line syntax is different.
cd build
DESTDIR=./tmp ninja install (This does install under build/tmp - where
the original prefix is /usr/local, my choice for a self-compile instead
of /usr)
In addition to setting the environment variables listed, I also set
QT_DEBUG_PLUGINS=1 to get more information at runtime.
I think there is some inconsistency in the variables settings -
XDG_DATA_DIR uses ./tmp/usr/local/share, but QT_PLUGIN_PATH uses ./lib
where I think it should be ./usr/local/lib64/plugins (. should be same
as $PWD, lib vs lib64 depends on the local setup, but that variable
needs the /plugins on the end) and LD_LIBRARY_PATH should also be
./usr/local/lib64 not just ./lib. Finally the executable should be
./usr/local/bin/kmymoney (It's OK for the readme to use /usr and not
/usr/local, that's only my personal preference, but if so, should
XDG_DATA_DIR include the "local"?)
So - If I grep through the output cause by setting QT_DEBUG_PLUGINS,
and look for "Found metadata" or "loaded library" also mentioning
ofximporter.so, I get
Found metadata in lib
/home/jack/KDE/KMM/build50debug/tmp/usr/local/lib64/plugins/kmymoney/ofximporter.so,
metadata=
Found metadata in lib /usr/lib64/qt5/plugins/kmymoney/ofximporter.so,
metadata=
Found metadata in lib /usr/lib64/qt5/plugins/kmymoney/ofximporter.so,
metadata=
loaded library "/usr/lib64/qt5/plugins/kmymoney/ofximporter.so"
Plugins: ofximporter loaded
Found metadata in lib
/home/jack/KDE/KMM/build50debug/tmp/usr/local/lib64/plugins/kmymoney/ofximporter.so,
metadata=
Found metadata in lib
/home/jack/KDE/KMM/build50debug/tmp/usr/local/lib64/plugins/kmymoney/ofximporter.so,
metadata=
Found metadata in lib
/home/jack/KDE/KMM/build50debug/tmp/usr/local/lib64/plugins/kmymoney/ofximporter.so,
metadata=
So it finds the new plugin four times while looking for metadata, but
finds the system version twice, and still manages to load the system
version instead of the new version.
Can anyone tell what I'm doing wrong?
I might yet uninstall my system version, to see if it does load the new
plugins. If so, then it's an issue with search order for all the
plugin dirs it uses. If it still won't load the new plugins, then I'm
really stumped.
Any other thoughts or suggestions?
Jack
