Jump to content
  • Advertisement
Sign in to follow this  
Dirge

File organization survey

This topic is 3366 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Inquiring minds must know! How do you organize your source and header files? Include and Source directories? i.e. Codebase/Include/Foo.h, Codebase/Source/Foo.cpp OR Codebase/Foo.h, Codebase/Foo.cpp etc... OR Some other way? What are the merits of one over the other? How should nested hierarchies work when using an Include/Source directory structure (i.e. Codebase/Include/FooLib/Foo.h OR Codebase/FooLib/Include/Foo.h)? I know this is a silly question but please humor me. :-)

Share this post


Link to post
Share on other sites
Advertisement
My reply won't help you directly since it's not C++, but I think it's also interesting to see how people organize in general - there is a lot more apart from code after all. You did say "survey", so that's my excuse for this somewhat tangential reply :)


In SVN, my structure looks like:

some-project
some-other-project
|
|-tags
|-branches
|-trunk
|
|-(same as on disk, except for temp data)

On disk, I have (for big project):

sol-engine-core - separate from game to prevent dependencies
|
|-bin/ - compiled class files from Eclipse (not in SVN)
| |-test/ - compiled unit test cases
| |-core/ - compiled class files for project
|
|-src/ - contains game-specific source code (package tree)
|-test/ - unit test cases source (package tree)

solariad - game files proper, set up, game logic, game loop
|
|-bin/ - same as above, not in SVN
|-content/ - first stage of asset pipeline, all raw assets are here
| |-art/
| |-audio/
| |-models/
|
|-data/ - contains all processed assets that are part of the game proper
|-dist/ - the redistributable "gold master", where everything comes together during the build process (Ant script) This is not in SVN
|-src/ - source package tree
|-web/ - everything related to solariad.com




Big disadvantage is that every processed asset is version-controlled twice, but I have more than enough disk space on my NAS so it hasn't been a problem yet. Asset pipeline in general is actually somewhat of a problem for me, but this is the "poor man's version" I came up with so far.

Share this post


Link to post
Share on other sites
One of the standard linux layouts is to have the structure:
code/include/*.h
code/src/*.cpp
this is good for compilation and library linking.
1) everything that needs to be is already sperated, you don't have to do any extra work to pull the cpp files out of the library.
2) everything else is already in one place, so your #includes can be shorter and you need less include directories to send to the compiler.

On the other hand, for smaller projects and subsystems I prefer the layout:
code/stuff/*.h,*.cpp
It means less jumping around the folder structure when I'm looking for things. But it does mean that folders have 2x the number of files. And you tend to have a lot of folders.

Another structure I'm quite partial to is:
code/*.h
code/platform_pc/*.cpp
it has some of the benifits of the first approach, with the locality of the second aproach.
Besides, I'd rather edit X files when an interfaces changes then have to look at code that is a jumble of #if _PLATFORM_X_ directives.

[Edited by - KulSeran on May 31, 2009 7:32:14 PM]

Share this post


Link to post
Share on other sites
"Codebase/Foo.h, Codebase/Foo.cpp etc..."

That is the only one Visual Studio is friendly with, so it's the one I use.

Share this post


Link to post
Share on other sites
Most of my projects are in C# so it's a little different, but for my projects I have folders for the different name spaces that I create and then all the source files for a name space go in that folder.

When I'm working with assets I tend to not keep them as organized as I should and have everything in the same Content folder. If I ever start work on a project big enough though I would probably have sub folders within the Content folder for UI, Models, Sound and anything else that the game would require.

Share this post


Link to post
Share on other sites
Sorry, I shouldn't have narrowed it down to c/c++ codebases. This subject relates to large codebases of any language.

Let me pose an additional question; How useful would it be to have a number of sub-directories as an additional organizational structure? In other words, if you were working on your graphics renderer and had a number of files related to models and textures (ex. not just model.cpp but model_loading.cpp, model_rendering.cpp, model_exporter.cpp, texture_loading.cpp etc...), does it make sense to have a denser hierarchy like:
Renderer/D3D/Include/Models/Model_Rendering.cpp, Renderer/Common/Include/Textures/Texture_Loading.cpp, ...

Share this post


Link to post
Share on other sites
Quote:
Original post by Dirge
Sorry, I shouldn't have narrowed it down to c/c++ codebases. This subject relates to large codebases of any language.


To an extent; but C and C++ have unique decisions to make because of the whole header vs. source file thing. :)

Share this post


Link to post
Share on other sites

<project-name>/
env/<compiler-version>/<compiler>.sln *
src/<project-name>/
src/ non-shared sources (usually .cpp & .hpp)
inc/ shared sources (usually .inl and no-extention)
env/<compiler-version>/ project specific data, usually just the .vcproj
bin/<config>/<project-name>/ tempory build data
dist/<config>/ distribution files, usually .dll and .exe

* vs2005.sln for visual studio 2005 (by naming the solution after the compiler-version I can use it as a readable variable - anyone got any other options I'm all ears)

The reason behind this is that some projects will have to be build with several compilers. There is one project at work that needs to be built for visual studio 6.0 to 2008, both 16, 32 and 64 bits where applicable(supporting legacy application is fun).

For .net I've found the default to be sensible enough :)

Share this post


Link to post
Share on other sites
Quote:
Original post by gekko
"Codebase/Foo.h, Codebase/Foo.cpp etc..."

That is the only one Visual Studio is friendly with, so it's the one I use.


Visual studio can cope with /include and /src directories. Just remember to add the include path to your include paths in the project settings and you should be all set.
When adding files, You just have to add the path, so rather than adding foo.cpp, add src/foo.cpp


Anyway, at present I stick with
src/*.cpp
include/*.h
test/*.cpp;*.h
obj/<build string>/*.o
bin/<build string>/*.*

No doubt, given a few more years of experimenting it will change *shrugs*

Share this post


Link to post
Share on other sites
Quote:
Original post by Dirge
Include and Source directories?
i.e. Codebase/Include/Foo.h, Codebase/Source/Foo.cpp
We used to do exactly that, until we realised how awful it was.
The context menu item in VS "Go to header" doesn't work unless they are in the same dir.
What's more, adding both the source file and the header to a project requires browsing for files to add twice, rather than a multi-select in one directory.

Keep them in the same dir.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!