hi, I thought about a better way handling the plugin-version entry in the desktop files. In my understanding, this version string is used to force a rebuild of each plugin after some binary-incompatible change has been made. This will also trigger API-changes to be applied, since during rebuilding, the plugins with incompatible API won't compile.
In kdevplaform, there is a script to update the desktop files. I've created some cmake scripts to handle this automatically during configure-time. For now, I am getting the version string out of the kdevplatform/interfaces/iplugin.h file into a cmake variable and after that I use cmake's configure_files function to generate the desktop files. The parsing of iplugin.h seems a bit hackish to me, so I'd propose to export the plugin version as a cmake variable from the FindKDevPlatform.cmake file, that gets installed along with the other development files. In KDevPlatform/KDevelop/quanta/others, the same cmake functions could be used to create the iplugin.h with the correct version set and create all desktop files without using the shell script to update the files. So updating the plugin version would be as easy as setting a variable in the FindKDevPlatform.cmake file (or somewhere else, this file just needs to export it to other projects). Other projects then just need to recompile their code after an update of the KDevPlatform version and fix all the compiling issues. Most of the time it's just okay to update the version number and everything runs fine, again. Well, I just wanted to ask, if this could work, as you have the better understanding of what this plugin version actually does. May be, I didn't take something important into account, yet. You can find the cmake code I did here: http://ktechlab.git.sourceforge.net/git/gitweb.cgi?p=ktechlab/ktl- j_ohny_b;a=blob;f=cmake/modules/KDevPluginVersion.cmake;h=99e2004f5c59a3db352f1b38fe44e9ac349dea97;hb=cmake_magic bye then julian
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ 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 Ktechlab-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
