Directory Structure

[S6k9GNh0]

Just out of curiosity, I've been looking at larger projects to see what seem to define the "industry standard" of project structure. What I've found is that nobody cares to follow any standard (lol). So, I ask all of you what you're preferred method of organizing your project is!

I currently am using something like this:

.
|-- Tuprules.tup
|-- bootstrap.sh
|-- submodule1
| `-- implementation1
|-- submodule2
| `-- implementation1
|-- test
| |-- Tupfile
| |-- example_input
| |-- test1.c
| `-- test2.c
`-- tools
| |-- tool1
| |-- tool2
| `-- tool3


Unfortunately, this is causing some complication while making build rules but the it looks nice on paper. :D

I'd also like to know about whether or not you organize where your builds are placed into! For instance, Tup will not allow you to properly generate a file outside of the folder you're currently in (which makes sense actually). I'm currently trying to find a proper work around or I'll have to introduce some new functionality.

[chrisname]

Depends on the kind of project. For most projects I use something like this:

project_name/
├── bin/
├── include/
│   └── project_name/
└── src/

For games I use this:

GameName
├── Release/
│   └── Data
│       ├── Bin
│       ├── Data
│       ├── Scripts
│       ├── Sounds
│       └── Textures
└── Source/
    ├── include/
    └── src/

For my kernel I use a modified version of the first one:

Redshift/
├── bin/
│   ├── initrd.fs/
│   │   ├── drivers/
│   │   └── programs/
│   └── redshift.fs/
│       ├── boot/
│       │   └── grub/
│       ├── programs/
│       ├── settings/
│       ├── system/
│       │   ├── devices/
│       │   ├── logs/
│       │   ├── mounts/
│       │   ├── processes/
│       │   └── settings/
│       └── users/
│           ├── default
│           │   └── .settings/
│           └── root
│               └── .settings/
├── include/
│   ├── boot/
│   ├── io/
│   ├── kernel/
│   ├── libc/
│   └── mem/
├── src/
│   ├── boot/
│   ├── io/
│   ├── kernel/
│   ├── libc/
│   └── mem/
└── tools/
    └── src/

[ascii]

How do you create those vertical and horizontal lines?

Anyhow my basic outline is:

program_name/
   -img/
   -src/
      -Makefile
      -scripts/
   -include/
   -Makefile

[S G H]

By default my project structure is:

Project
├Debug
│└Project.exe
├Release
│└Project.exe
├obj
│└Random compiler sh*t
└All files

ascii wrote:

How do you create those vertical and horizontal lines?

Read your nick, please. ;)

[kbw]

BSD Make projects tend to have a seperate directory for each compiled targed (such as a program or library). The is because the system make includes files are set up that as an assumption. It's a pattern I tend to follow.

[LB]

I have consistenly seen "bin", "lib", "src", "include" or "inc", etc. for most things, especially libraries. There's also README, LICENSE, AUTHORS, CONTRIBUTING, etc. which are mostly from GitHub conventions.

Some real-world examples:
http://github.com/udp/lacewing
http://github.com/LWJGL/lwjgl
http://github.com/twall/jna
http://github.com/Bukkit/CraftBukkit
http://github.com/orangeduck/CPlus
http://github.com/Mojang/Minecraft-API
(not really good examples but they're the ones I know off the top of my head)

There's no obvious standard but there seems to be a common convention, and there are tools that can process most libraries within reasonable extents.

I think the most annoying yet least avoidable thing is java code directory structure; packages like org.sun.jna result in paths like src/org/sun/jna/ until you get to any code. And what's worse is that internally packages are stored as just a single string with the dots included, so "java.lang" is in no way related to "java.util" despite both starting with "java". Folders can have dots in them, I don't see why packages have to be a messy nested structure when both internally and in documentation they are listed in flat form.

[DeXecipher]

I've been wondering what a proper and organized directory structure (in general) should look like myself. It seems I'm addicted to making things over complicated. I have a folder for design and documentation and separate that from the code repository which has a runtime-src/bin/lib and a code store-headers,imp

My current project has over 700 template folders but its organized in a top-down way and I probrably won't modify it too much when my project gets big. I first made some "template" components just by creating empty shells of folders and then I finally arrived at a singular template which was acceptable for my big project. Not enough time to do it all yourself, thats why there are teams, *sigh.

[BHX]

L B wrote:

I have consistenly seen "bin", "lib", "src", "include" or "inc", etc. for most things, especially libraries. There's also README, LICENSE, AUTHORS, CONTRIBUTING, etc. which are mostly from GitHub conventions.

I disagree with that because I know I saw README/LICENSE/AUTHORS/CONTRIBUTING/etc in open source projects prior to 2008 when GitHub launched.

[Null]

For larger projects my default directory structure is

Project
│
├── bin ; all binaries and libraries
├── obj
│ ├--- Debug
│ │ ├── sub_proejct_a
│ │ ├── sub_project_b
│ │ ├── library_x
│ │ ├── library_y
│ │
│ ├--- Release
│ ├── sub_proejct_a
│ ├── sub_project_b
│ ├── library_x
│ ├── library_y
├── src
├── sub_project_a
├── sub_project_b
├── library_x
├── library_y

I don't know why but I never put headers into a separate directory, so I don't have "include" directory.

[LB]

Generally "include" is for headers the client would need to #include, whereas implementation headers go with the implementation files.

[chrisname]

I put all header files in the include folder.

[S6k9GNh0]

I just changed the format of my project a few days ago to src;lib;include;bin. It simplifies build rules while organizing interface from implementation in a way that's easy to understand.

[chrisname]

I would usually only have bin xor lib, not both; if I'm writing a library I use lib only, but if I'm writing a program or a program with a library then I use bin only.

[S6k9GNh0]

I package certain projects into the project (like a custom boost tree made from Boost BCP and Boost Log) which why I have a lib folder. The lib folder has its own src/include/bin directories.

[S G H]

About that lib folder, instead of having one, I have a folder which contains all libraries I use, and always have the Library Inclusion directories point to them, so I don't need one.

[chrisname]

That's sort of what I do. On Linux of course I have /lib and /usr/lib and on Windows I have a C:\Libraries directory.

[LB]

The problem is when different projects use different versions of libraries for one reason or another.

[chrisname]

I try to make all my projects use the latest stable version. Which is why I prefer to use a rolling release Linux distro like Arch Linux. Unfortunately I can't install Arch on my PC because it doesn't recognise my wireless adaptor and I don't have a wired connection.

[S6k9GNh0]

Unfortunately, I've realized that in some cases, doing that isn't a very reliable choice. Another problem is when the "stable" library doesn't have the set of patches you want or most distributions don't provide a responsible compilation of that library. For instance, Arch Linux doesn't provide the multi threaded or debug versions of the boost library. So its either I package them myself or get the user to download and install it themselves... I'm not sure which one is more correct but I know I can do it correctly and the user may not.

[S G H]

On windows, I have different folders for different versions also. :3