[Kmymoney-devel] Two instances at once, was: Debugging plugins

[Jack]

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