[prev in list] [next in list] [prev in thread] [next in thread]
List: kdevelop-devel
Subject: Re: use cmake to support kdevelop plugin versioning
From: Aleix Pol <aleixpol () kde ! org>
Date: 2010-07-18 21:18:15
Message-ID: AANLkTil35v2y6XQiwD4_bVy2KpQq5jJ6zD-NMYRTE0eu () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Sun, Jul 18, 2010 at 7:28 PM, Andreas Pakulat <apaku@gmx.de> wrote:
> On 18.07.10 16:10:52, Julian B=C3=A4ume 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 expor=
t
> 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.
> 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.
>
> 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.
>
> Andreas
>
> --
> You learn to write as if to someone else because NEXT YEAR YOU WILL BE
> "SOMEONE ELSE."
>
> --
> KDevelop-devel mailing list
> KDevelop-devel@kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
I was about to write something similar.
We wouldn't win that much anyway.
Aleix
[Attachment #5 (text/html)]
<div class="gmail_quote">On Sun, Jul 18, 2010 at 7:28 PM, Andreas Pakulat <span \
dir="ltr"><<a href="mailto:apaku@gmx.de">apaku@gmx.de</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;"> <div class="im">On 18.07.10 16:10:52, Julian Bäume \
wrote:<br> > I thought about a better way handling the plugin-version entry in the \
desktop<br> > files. In my understanding, this version string is used to force a \
rebuild of<br> > each plugin after some binary-incompatible change has been made. \
This will<br> > also trigger API-changes to be applied, since during rebuilding, \
the plugins<br> > with incompatible API won't compile.<br>
><br>
> In kdevplaform, there is a script to update the desktop files. I've \
created<br> > some cmake scripts to handle this automatically during \
configure-time. For<br> > now, I am getting the version string out of the<br>
> kdevplatform/interfaces/iplugin.h file into a cmake variable and after that \
I<br> > use cmake's configure_files function to generate the desktop files. \
The<br> > parsing of iplugin.h seems a bit hackish to me, so I'd propose to \
export the<br> > plugin version as a cmake variable from the \
FindKDevPlatform.cmake file, that<br> > gets installed along with the other \
development files.<br> <br>
</div>Personally I disagree with that, the version number shouldn't be \
changed<br> in the .desktop files automatically. This should always be a manual<br>
action that the repsonsible developer of the plugin should do.<br>
Increasing the plugin version may also be done as part of a behavioural<br>
change (where the API stays the same) and in such cases you really don't<br>
want plugins that haven't been adjusted loaded into a running app as it<br>
may cause undefined behaviour.<br>
<br>
The plugin version declares a dependency of the plugin onto a specific<br>
runtime version of kdevelop/kdevplatform and hence this dependency<br>
shouldn't be automatically generated.<br>
<br>
Andreas<br>
<br>
--<br>
You learn to write as if to someone else because NEXT YEAR YOU WILL BE<br>
"SOMEONE ELSE."<br>
<font color="#888888"><br>
--<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" \
target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
</font></blockquote></div><br><div>I was about to write something \
similar.</div><div><br></div><div>We wouldn't win that much \
anyway.</div><div><br></div><div>Aleix</div>
--
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic