use cmake to support kdevelop plugin versioning
julian at svg4all.de
Sun Jul 18 20:46:11 UTC 2010
On Sunday 18 July 2010 19:28:13 Andreas Pakulat wrote:
> On 18.07.10 16:10:52, Julian Bäume wrote:
> > 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.
> Personally I disagree with that, the version number shouldn't be changed
> in the .desktop files automatically. This should always be a manual
> action that the repsonsible developer of the plugin should do.
Okay, you got a point here :) I totally agree, that the maintainer should be
aware of what is happening.
> Increasing the plugin version may also be done as part of a behavioural
> change (where the API stays the same) and in such cases you really don't
> want plugins that haven't been adjusted loaded into a running app as it
> may cause undefined behaviour.
Did this happen, yet? I think, this case is somewhat unlikely but of course,
it can happen. So after thinking about that a little bit, doing this
automatically doesn't seem to be a good idea any longer.
> The plugin version declares a dependency of the plugin onto a specific
> runtime version of kdevelop/kdevplatform and hence this dependency
> shouldn't be automatically generated.
Okay, but IMHO there should be a way to better support developers and
maintainers using the PluginController. I thought a bit about that. What about
allowing plugin maintainers to define a set of "working versions?" (i.e. more
then only one, since it has to be an exact match) At least for us, it's most
likely that an update of the version won't break anything within most of our
plugins. We are at least 2 developers using different versions of KDevelop and
therefor have different versions of KDevPlatform installed. This has been
working okay, so far, I just thought, that we need to do something about the
patches, each of our developers has to maintain to have the correct version
number within the desktop files. Especially when it would work with other
Beside this, we are getting along very good with the KDevPlatform libs and
it's a great help to use it. May be, we can come up with a solution, that
works a bit better, than it's now. IMHO, this can't be so hard ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 490 bytes
Desc: This is a digitally signed message part.
More information about the KDevelop-devel