2010/7/18 Julian Bäume <julian@svg4all.de>
I just pushed some cmake code into a cmake_magic branch. Can you test it and
tell me, if it still compiles for you and you are able to load our plugins? It
works okay for me.

Tested with GUI tools (see tutorial on wiki:


) and it works well. It generated the .desktop files from .desktop.in files, and i was able to run unit tests and also open circuit documents.

I did a little trick to find out the plugin version. If this works, I will
propose this solution to the KDevelop people and ask them to export a cmake
variable in their FindKDevPlatform.cmake script.

Since this plugin versions purpose is to force a recompilation of the module
before it can be loaded, this solution should work fine. If the API has been
changed, it won't compile and has to be fixed to apply the new API. If nothing
important has changed for the plugin, it should compile fine and the desktop
file will be updated regarding the installed kdevplatform version.

I will ask on the kdevelop ML later, if this could make any problems (along
with the proposal to integrate these changes) and if this works okay for both
of us, we should use it. This should make life with different versions more
easy for us developers. We only have to make sure, our code compiles with all
stable releases of kdevplatform that we support. This is some testing-work
todo, but we would have done that, anyway.

There is one open issue, I want to fix, before merging this into kde4-port
branch. For now, we need 2 lines of cmake code to generate and install the
desktop file for a plugin. I want to write a macro that takes the desktop
filename as a parameter and creates these 2 lines. I thought about something
like "ktl_install_desktop( ktlproject.desktop)" which will then expand to
configure_file(....) install(....) commands.

Looks good ;)

bye then


This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
Ktechlab-devel mailing list