On 2014.03.31 05:32, Christian Dávid wrote:
Am Sonntag, 30. März 2014, 19:08:08 schrieb Jack:
It would appear in KDE you need to pollute your application name
space to debug a plugin which means you cannot simultaneously have
a devel version and a release version running at the same time.
Ah, you have run into one of my recurring rants. I have never
succeeded (on Linux) to install two versions of KMyMoney at once […]
As this comes up quite often I retried my approach from scratch. You
"just" need all build dependencies installed. I did it with Linux,
but it should be the same on windows except one command (and you have
to replace cd). If you test it and it works as well, I can publish
it on techbase. With windows specific stuff it would even be better.
I finally got to try this, and it does seem to work - with one
additional item.
# Get sources
git clone git://anongit.kde.org/kmymoney
cd kmymoney/
Obviously here you can make any changes you want. In my case, I was
testing a patch from reviewboard.
# Create directory for out of source build
mkdir build
cd build/
# Run cmake and set an install prefix
# "make install" will copy all files there
cmake -DCMAKE_INSTALL_PREFIX=../install/ ../
I actually use "cmake ." from within the build directory, but I don't
think that matters.
# Build and install
make
make install
cd ../install/
# Give KDE's trader the chance to find the new services (= our
plugins)
# I guess on Windows (and maybe OS X) this command is different.
# You need to set an environment variable to your current folder
export KDEDIRS=`pwd`
# Here you need one more item:
export LD_LIBRARY_PATH=`pwd`/lib64
# without this, I was getting "bin/kmymoney: symbol lookup error:
bin/kmymoney: undefined symbol: _ZN10MyMoneyTag4nullE"
# Also, if you type the full path instead of using `pwd` and put all
this in a script, then you can call the script from anywhere, not just
the install directory. Also, since the script is run in a subshell,
you don't have to reset the environment variables afterwards.
# Refresh cache of the trader
# after the next run of make install you do not need this again
kbuildsycoca4
# Here you can test if it worked
# It does not show the library path but X-KDE-PluginInfo-Version
contains the
# version. At the end is the git commit.
ktraderclient --servicetype "KMyMoneyPlugin"
# run your own build
bin/kmymoney
This allows you to install multiple versions of KMyMoney at the same
time. You just have to set and unset KDEDIRS and run kbuildsycoca4.
Using a script, I don't think you need need to unset/reset KDEDIRS and
LD_LIBRARY_PATH.
If you also want to run them at the same time you can use your IDE.
This is the way you should do it anyway as it is quicker for every
day use.
KDevelop and QtCreator allow you to set a "run environment". Just
tell them to set KDEDIRS to the appropriate folder there. Your IDE
must install KMyMoney every time and execute "kbuildsycoca4" before
you run KMyMoney (KDevelop has no direct option for this, you need a
script — I think).
One problem left: If you run another instance of KMyMoney now, you
have to rebuild the cache (kbuildsycoca4) as SyCoCa tracks the files
in it's cache but not the environment variable. So it doesn't notice
that a service is no longer available if you just change KDEDIRS (but
it notices if you remove or update a .so/.desktop file).
I think there are also other issues such as finding the right icons. I
wonder if there is a way to have the script set a temporary directory
for the ksycoca cache, so outside that subshell it continues to use the
main cache, but within it uses the newly built one. I guess this will
take a bit of reading of the ksycoca4 docs.
More tutorials on traders and the system configuration cache (SyCoCa)
are available on
http://techbase.kde.org/Development/Tutorials#Services:_Applications_and_Plugins
Ever thought of breaking KMymoney out of the dependency on KDE? It
would have much wider appeal.
A lot of KMyMoney current appeal comes from the use of KDE. And from
experience I know: That would result in solutions which are as
complex as the the current ones but with less documentation, less
testing, horrible maintenance and less people who can help.
> […]
Also, it might be worth exploring the impacts of the coming switch
to Frameworks - if it will make working on OS-X and Windows easier,
it may be worth accelerating, although I fear it may be as difficult
and painful as the switch from kde3 to kde4.
Frameworks will make the build on OS-X and windows easier.
I'm afraid the switch may be as hard as from KDE3 to KDE4, but I do
think it will be worth the effort.
Thanks for getting me to try this again. It's really a great help to
be able to run two versions without needing to use a VM.
Jack
_______________________________________________
KMyMoney-devel mailing list
KMyMoney-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmymoney-devel
