Author Topic: SDK version mismatch  (Read 18344 times)

Offline eckard_klotz

  • Almost regular
  • **
  • Posts: 194
SDK version mismatch
« on: November 14, 2010, 10:05:11 am »
Hello Everybody.

After installing the newest nightly from the 7th of November 2010 I tryed to install the plugins FileManager and PowerShell but since the versions currently available under the project-page Code::Blocks IL plugins (http://developer.berlios.de/projects/cbilplugin/) are from July 2009 I've got the following errors:

Quote
SDK version mismatch for FileManager (1.11.12). Expecting 1.11.13
SDK version mismatch for PowerShell (1.11.12). Expecting 1.11.13

I posted a bug-description (#017702   SDK of Code::Blocks has changed again) I hope that the project of this 2 plugins is still alive and the new compiled versions will be load up soon. But I have some questions about this.


1. Why are this plugins no core-plugins (especially the file-manager)?
2. If the c::b core-project desides to use a new sdk-version is there a central announcement-place where this information for plugin-developers will be posted? (I know that the plugin-developers are responsible to hold their software up-to-date, but currently as user I wonder if it is my job to inform the plugin-project about changes.)

OK, please don't take me wrong if I choosed the wrong words I don't wont to be impolite. But since I think about write an own plugin for C::B for my doxygen helper-tool Moritz some when in the future it will be also importend for me to know about such things.

Best Regards,
                      Eckard Klotz.

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: SDK version mismatch
« Reply #1 on: November 14, 2010, 10:19:45 am »
You have a very good point, we should more clearly announce the SDK changes.

We will think about this :
* mainling list (for the plug-in developers ...)
* somewhere on the home page

Do note however : no plg-in is broken on the official version, only the nightlies. But since the nigthlies are very stable and widely used, we should do a better effort in supporting the plug-in developers.

As for the 2 mentioned plug-ins, I think they should become contrib plug-in, let's discuss this with th original author.

Good to hear you are going to write a plug-in. Did you check with our current doxygen plug-in ?
Maybe you can join forces with its author  to improve on the existing one ... just an idea ;-)

Thanks for the feedback.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: SDK version mismatch
« Reply #2 on: November 16, 2010, 01:37:21 pm »
1. Why are this plugins no core-plugins (especially the file-manager)?
We had several attempts to transfer these into C::B's repo as core plugins, hence the current state is "they need some clean-up" to my knowledge. It's better to ask dmoore about this.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: SDK version mismatch
« Reply #3 on: November 16, 2010, 03:46:40 pm »
IMO, we should modify our sdk to allow any plugin compiled with a lower version sdk to be run. My idea is-

Code
SDK_Version = {Release}.{Major}.{Minor}

E.g.,
Release|Value
10.05|1
11.05|2

Similarly {Major} and {Minor} will be assigned depending on the maturity of the release.

Rules for {Major} value change -
a) Deletion of any sdk class / function.
b) Interface change (can be parameter type, function return type change)

Rules for {Minor} value change-
a) Addition of new class / function.
b) Interface change (can be parameter type, function return type change) but old interface is still intact.

Now when C::B sees any sdk version change-
a) If {Minor} has changed, load & run plugin without warning.
b) If {Major} has changed, load & run plugin with warning. Warning should inform users that the plugin could be unstable with new sdk version; so use it with a grain of salt.
c) If {Release} has changed, inform users to source for a newer version of that plugin.

My point is even a small change in sdk should not force a plugin to be recompiled, especially when the plugin under question is not affected by the change.

Anyway this is just a draft idea. Feel free to update/comment.


I'm also not in favour of the idea to add plugins to the repo to ensure that they stay updated when we change sdk version. We do have couple of almost unmaintained plugins and I don't want to see their numbers increase any further. We should add plugins to our repo only when someone is there to maintain it. :)
Be a part of the solution, not a part of the problem.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: SDK version mismatch
« Reply #4 on: November 17, 2010, 12:13:22 pm »
We do have couple of almost unmaintained plugins [...]
Which one are these?

BTW: My idea was to create a second repo / project just for the contrib plugins, where plugin authors have full access. This would no clutter the core, but still allow to have everything in one place, easy to be maintained. Becoming a member f this project would be as easy as to provide a working draft of a plugin (which then of course can be further developed). Then upon a release we can decide which contrib plugins are "mature enough" to make it into a distribution. Probably even through a poll in the forums.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: SDK version mismatch
« Reply #5 on: November 17, 2010, 02:45:52 pm »
We do have couple of almost unmaintained plugins [...]
Which one are these?

cb_koders, HexEditor, CodeStat, wxSmith...

BTW: My idea was to create a second repo / project just for the contrib plugins, where plugin authors have full access. This would no clutter the core, but still allow to have everything in one place, easy to be maintained. Becoming a member f this project would be as easy as to provide a working draft of a plugin (which then of course can be further developed). Then upon a release we can decide which contrib plugins are "mature enough" to make it into a distribution. Probably even through a poll in the forums.

Good idea. But I still want to see the problem of version mismatch to be ironed out. It will give more flexibility to a plugin developer. :)
Be a part of the solution, not a part of the problem.

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: SDK version mismatch
« Reply #6 on: November 17, 2010, 03:17:54 pm »
CodeStat is rather stable. (I have done some changes long time ago, so I know the code a little bit)

HexEditor works ok.

wxSmith : currently +- unmaintained, though some people have been contributing to it. But very important plugin.

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: SDK version mismatch
« Reply #7 on: November 17, 2010, 03:30:55 pm »
CodeStat is rather stable. (I have done some changes long time ago, so I know the code a little bit)

HexEditor works ok.

wxSmith : currently +- unmaintained, though some people have been contributing to it. But very important plugin.

They are stable. But we do need a developer to maintain them. :)
Be a part of the solution, not a part of the problem.

Offline eckard_klotz

  • Almost regular
  • **
  • Posts: 194
Re: SDK version mismatch
« Reply #8 on: December 02, 2010, 12:27:44 pm »
Hello Everybody.

Only for the protocol:

Since the new versions of the plugins FileManager and PowerShell are available since December the first (Thanks to dmoore) both plugins can now be used with the current nightly again (until the sdk-version changes again).

Best Regards,
                    Eckard Klotz

Offline eckard_klotz

  • Almost regular
  • **
  • Posts: 194
Re: SDK version mismatch
« Reply #9 on: January 04, 2011, 08:01:08 am »
Hello Everybody.

I wish for all a happy new year.

May it be possible, that the sdk-version has changed again?
After downloading the latest nightly (from December the 28th) i have problems installing the PowerShell.dll

Quote
D:\NotSaved\DatenAlt\LocalHome\CD_Diverse_SW_Tools\Cpp\CodeBlock\NightlyBuilds\2010_12_28\bin/share/codeblocks/plugins/PowerShell.dll: not loaded (missing symbols?)

But the FileManager seams to work.

Best Regards,
                   Eckard Klotz.


Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: SDK version mismatch
« Reply #10 on: January 04, 2011, 10:32:16 am »
May it be possible, that the sdk-version has changed again?
To solve it once and forever we should really integrate these two plugins (FileManager and PowerShell) in the main source tree.

dmoore & devs: Do you have any objections? What's still missing? I don't see any - I am using especially FileManager a lot without any issues.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline eckard_klotz

  • Almost regular
  • **
  • Posts: 194
Re: SDK version mismatch
« Reply #11 on: January 31, 2011, 09:21:53 am »
Hello C::B developers.

Since there is no new version of the power-shell plugin but the file-manager plugin is still working even it seams to have nearly the same build-date (compared to the currently used sample-rate of the nightlies) I wonder if there may be an additional interface-problem in the plugin-interface of C::B?

On the other hand if there is a need for a higher build-frequency for plugins and the developer does not react, it may be that the developer has decided to stop the further development. Well this is a freeware-project and the development of plugins is also a voluntary act of work. And I think I have to respect the decision of every c::b developer to pay more attention to other aspects of live like work or family (especially in this years where the economic crisis is still a problem in many countries).

So if somebody knows that dmoore is not able to maintain his plugins any more it would be kind to inform us and I think after that there is no need to discus this any longer.

Best regards,
Eckard Klotz.
   

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: SDK version mismatch
« Reply #12 on: January 31, 2011, 12:12:05 pm »
No general objections from my side.

I could do the automake and debian stuff (some [little] fixes are needed to make it work with trunk).

But I would suggest to remove the non-aui part if filemanger is in our repo.
There are also some minor issues (build warnings and the use of wxAuiNotebook instead of our derived cbAuiNotebook).

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: SDK version mismatch
« Reply #13 on: February 06, 2011, 08:10:31 am »
Sorry for not noticing this thread (much) earlier. In response to requests in other threads, I did some hacking on both plugins today. I made some more extensive changes to the PowerShell plugin because it needed the most help in terms of usability. (So extensive that I decided to rename it ToolsPlus because it essentially works as a replacement for the current Tools menu.)

I could do the automake and debian stuff (some [little] fixes are needed to make it work with trunk).

Jens: you are best placed to handle this.

Quote
But I would suggest to remove the non-aui part if filemanger is in our repo.

I can deal with this (there's some other stuff in there that needs to go as well)

Quote
There are also some minor issues (build warnings and the use of wxAuiNotebook instead of our derived cbAuiNotebook).

I can probably take care of most of these too. (Hopefully the right way).

I think it would be good to get these plugins into contrib. They are still pretty rough, but I think having them in contrib will get more eyeballs on them and get them up to scratch. Not having to keep up with the ever changing SDK will also give me more time to work on features. I'll be trying to make a little more time for C::B hacking in coming months, but it's tough for me to devote a lot of time to C::B due to the usual work and family commitments.

I like Morten's suggestion to separate the contrib plugin repo from the core and open it up to more devs.

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: SDK version mismatch
« Reply #14 on: February 06, 2011, 09:05:25 am »
Update: I fixed the compiler warnings (4 unsigned int casts required after first checking for negative value). Non AUI stuff removed (Flatnotebook), broken file monitoring code removed (GIO and gnomevfs).