Software File Structures

Among the file structures I analyzed and already merged are:

Stands for root directory of a project. It is compulsory for all projects and systems.

Holds initial configurations for development environment such as pre-processors variable definitions, and etc.

Holds application protocol designs. It should be structured with its own type.

Holds supportive materials like images, logo, Javscript, CSS, and etc.

For holding essential executable binaries. It has:

1. Strictly one level hierarchy (no sub-directory)
2. Holds only executable

For Operating System, this should only holds operating system critical system binaries. If you need to add yours, you should use /usr/local/bin instead.

For Project, this should be your compiled binary outputs ready for packaging.

For holding static files for bootloading.

1. Holds data file strictly related to booting or initialization.

For holding build packaged artifacts ready for distribution, build configurations, build recipes, and more.

For holding the version control changes documentation.

For holding codes to compile the application (e.g. main.c or main.go). The output can be stored to project bin/ directory as the directory name.

For holding the first-step documentations to contribute back to the project.

Holds modular components.

Holds project level configuration files.

Holds project level configuration files when the /configs is intrusive for the project tools.

For holding device IO files.

For holding documentations.

For holding device specific system configurations.

For holding Git version control data.

Project level C-headers directory.

Private directory for project internal usage.

For holding shared libraries.

For declaring the Licenses of the projects.

For mount point of removable media.

For holding the instructions in order to make the project.

Temporary mounting point.

Adds-on software packages. Pathing inside /opt must complies to the original structure. If /opt/<software>/bin is available, for execution, it should be linked, not copy over to /bin or /sbin.

For static website generator artifact ready to be published.

For organizing library codes for inline code distributions.

known to hold root account data. This is optionally created by developer.

known for rendering README.md for a version control repository.

data relevant running processes.

System-level essential binaries only for administrators.

1. Strictly one level hierarchy (no sub-directory)
2. Holds only executable

This should only holds operating system critical system binaries. If you need to add yours, you should use /usr/local/sbin instead.

Project level automation scripts for simplifying projects.

Project level automation scripts for simplifying projects when /scripts is intrusive for the project tools.

Data for services provided by this system.

Holds project source codes.

Compulsory for:

• C Programming Language
• Git

Project level test files.

Temporary directory.

Known as UNIX source directory for holding read-only contents

Primary location of holding software executable.

Primary location of holding C programming language headers.

Primary location of holding compiled library object files.

Localized system. All locally installed software should be placed inside this directory in accordingly. It has its sub-directory like:

• bin - local binaries
• etc - host specific system configurations for local binaries
• games - game binaries
• include - C header files
• lib - compiled library codes
• man - manuals
• sbin - system binaries
• share - architecture independent hierarchy contents
• src - source codes

known to hold variable data.

temporary file preserved between system reboot.