Explanation of source tree?

[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...

[beldaz]

I've put the details I could surmise, along with the responses from oBFusCATed, into a wiki page. I'm hoping it's useful to other people, it is to me in any case. I'm still unclear about some of the stuff in base, build_tools/scrooge and tools. I'm guessing some of this is legacy stuff that is no longer used. Please say if you know otherwise.

[ollydbg]

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...

I think the reason that why cb have a libcodeblocks.dll is that the exe file can not export it's function (At least the normal way), this is the same reason that why GCC plugin feature can't works on Windows in the normal way. (There is a hack that we can let the exe to export all the functions, but it's a hack)

You can have a look at Enhanced Dynamic Linking for MS-Windows, especially the section "The sub-DLL solution", so the practical way is to create a big SDK DLL file, and put all the core functionality there. And all the plugins should depend on this big SDK DLL.

I've put the details I could surmise, along with the responses from oBFusCATed, into a wiki page. I'm hoping it's useful to other people, it is to me in any case.

Very nice work, thanks!!!

[beldaz]

Thanks ollydbg - I've added those details to the wiki for posterity.

[ollydbg]

Thanks ollydbg - I've added those details to the wiki for posterity.

I think C::B's source/structure are quite easy to understand.  
Each plugin's sources were in its own folder, you just add some even handlers in plugins, and manipulate something....
Or, you can set a BP, and debug C::B in C::B.

If you have some questions, just ask here

[beldaz]

I think C::B's source/structure are quite easy to understand.
Each plugin's sources were in its own folder, you just add some even handlers in plugins, and manipulate something....
Or, you can set a BP, and debug C::B in C::B.

Like man pages, it all makes sense if you already know it. As I mentioned in my first post, many directory names are ambiguous, and I'm just the kind of person that likes to know where everything is before doing anything. I've also worked on development efforts where the structure is rigidly defined and you get in trouble putting code in the wrong place...

If you have some questions, just ask here

No worries: expect plenty more.

[stahta01]

I added a section on CB Folders that tends to contain Third Party source code.

http://wiki.codeblocks.org/index.php?title=Source_hierarchy#Third_party_source_code_Folders

I think it might help newbie developments understand which areas needs to have patches normally submitted upstream.

I hope its the CB Devs consider think a proper thing to do.

Tim S.

[ollydbg]

I added a section on CB Folders that tends to contain Third Party source code.

http://wiki.codeblocks.org/index.php?title=Source_hierarchy#Third_party_source_code_Folders

I think it might help newbie developments understand which areas needs to have patches normally submitted upstream.

I hope its the CB Devs consider think a proper thing to do.

Tim S.

Thanks Tim.

BTW: I can't find the official link of depslib project, I think it is dead project?

[MortenMacFly]

I think it is dead project?

Yes, it was abandoned years ago. But its still working, so we "maintain" it meanwhile... ;-)