Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Explanation of source tree?

(1/3) > >>

beldaz:
As you've probably gathered from my other posts, I'm new to the C::B development scene, so I'm prone to asking naïve questions. I'm hoping others may benefit from good answers to them ;) FWIW I have already scanned through the various tips, coding style, and architecture overview available on the wiki, and I have browsed the doxygen-generated documentation from the SVN trunk.

I'm trying to navigate the source tree, in order to understand the layout. The top-level src directory has a large number of folders, so clearly a lot of effort has gone into separating different components of the code. However, to a newbie like me only some folders at the top level src directory are obvious (plugins, scripts), whereas many are a little ambiguous: base, sdk and src could all mean the same thing; as could build_tools and tools. I can make a guess as to what templates, mime and i18n and wxsmith cover, but they still aren't obvious.

Is there a guide to what goes where? If not, would someone mind giving a brief explanation of what the different folders within src are for?

Many thanks,

Beldaz

oBFusCATed:
include - header files for libcodeblocks, these headers are used by the plugins and the main application
sdk - cpp files for libcodeblocks, also all the bundled libs have been put here (wxscintilla, wxpropgrid, scripting)
src - header and cpp files for the main executable
plugins - all plugins go here
plugins/contrib/ - all contrib and non core plugins go here

beldaz:
Thanks, that makes sense. I hadn't appreciated the separation between the main executable and the codeblocks dll. What's the reason for this separation (as opposed to a monolithic executable)? I've dealt with dlls as a way of sharing common code, but clearly that doesn't apply here. Is it to speed loading at startup?

oBFusCATed:
libcodeblocks is used by all plugins...

beldaz:
Well, the plugins could know about the available functions and classes (through sdk.h) without them being contained in a DLL, I think. It looks like the plugins are DLLs themselves that are called in from the codeblocks executable, so it's not as if each plugin runs as its own process and makes independent use of libcodeblocks, right?

In any case, I'm just trying to get my head around the general architecture and design choices, so please don't mind my prying...

Navigation

[0] Message Index

[#] Next page