Author Topic: C::B development SDK  (Read 5043 times)

Offline jmccay

  • Almost regular
  • **
  • Posts: 202
C::B development SDK
« on: July 31, 2005, 02:55:32 am »
I am just starting looking into developping a pluggin.  Sorry if this question may seem obvious.  Since this is just headers and libraries, I assume this is for linking against.  Correct?  Are archives (.a) for dynamic linking or static linking?  What do people normally do?  I would assume they're for dynamic linking.  I haven't yet developed with libraries using something other than VC++ 6.0, and that was a while ago.  It might be a little bit before I get my footing again.

Thank you.
jmccay
OS: WinXP, Win98 SE, & sometimes Linux

a little light reading from the wxWidgets 2.6.2 readme: A detailed 2000-page reference manual is supplied in HTML, PDF and Windows Help form: see the docs hierarchy.

Offline darklordsatan

  • Almost regular
  • **
  • Posts: 132
    • http://eviltrend.sf.net
Re: C::B development SDK
« Reply #1 on: July 31, 2005, 05:53:54 am »
.a are the unix equivalent to .libs, so they could be static libs or dynamic ones (requiring a dll). IIRC, the one in code::blocks is meant to be for dynamic linking, just look at a huge codeblocks.dll in your C::B installation path.

Actually, the SDK is pretty clean in the sense of the sources (usually very tidy and easy to understand - although theres a lack of comments), but the structure is a little bit unclean, since its not a SDK framework in the usual way. You see, when building a plugin, you link the required C::B library and the WxWidgets ones, but then you include the headers that you require yourself. Theres no single .h or a couple like in most plugin frameworks, but youll usually want to check at \src\sdk folder to see what you need.

The best thing to do is to check out the sources of the already existing plugins, to watch the structure and the common functions and classes they use, like the ones to get a pointer to the editor, to the active project/workspace, to save/load pluging setting and else.

To clarify a little bit, what I meant with the last couple of paragraphs is that C::B's SDK (leave aside the fact its an open source app)  gives you -almost?- full control over the app, as it exposes most of the set of functions available to the main app itself to you, while in other plugin frameworks usually you only have a little set of functions to deal with, and you have a very reduced power in the sense of what you can do with the app through a plugin.
« Last Edit: July 31, 2005, 06:02:05 am by darklordsatan »

Offline Urxae

  • Regular
  • ***
  • Posts: 376
Re: C::B development SDK
« Reply #2 on: July 31, 2005, 09:40:27 am »
One of the default plugins is the Code::Blocks plugin wizard, which should help you set up a project for your plugin. It generates skeleton source files and sets the project to produce a dll. You'll still have to add the SDK path to the linker options, but it pops up a message about that. To be able to use your plugin, just put its dll in <C::B dir>/share/CodeBlocks/plugins.
You might want to do this in a separate install/compile of Code::Blocks from the one your're running as bugs in the plugin may crash C::B, and debugging is easier that way too. Note that you might have to enable multiple running instances of C::B in order for this to work.