User Tools

Site Tools


devel:directory_structure

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

devel:directory_structure [2009-07-12 19:24] (current)
Line 1: Line 1:
 +{{update}}
 +
 +This article describes the standard directory structures used in the project: source code directories,​ runtime directories on various platforms.
 +
 +⇒ //"​Source Directory Structure Proposal"​ by skyjake on April 14, 2006 at 13:56 on [[http://​deng.sourceforge.net/​blog/?​p=37|dengDevs]]//​
 +
 +Now that we are using [[svn_repository|Subversion]],​ it's feasible to think about such things as bringing some consistency into the Doomsday source directory structure. I think the following new principles should form the basis of a new directory structure.
 +
 +  *  All file and directory names should be in lower case. Upper case letters should only be used in special cases (for example, Unix-style README, INSTALL files).
 +  *  Instead of using file type as the root level structure (Defs, Src, Include) we should use the logical module (jhrp, common, engine, plugins).
 +
 +The new structure would look something like this:
 +
 +<​code>​
 +build/ ​        (all build/​project-related files, incl. built binaries)
 +    win32/ ​    ​(windows projects and scripts)
 +    mac/       ​(Xcode project)
 +    unix/      (Unix/Linux build scripts)
 +engine/
 +    scripts/ ​  ​(engine scripts: makedmt.py)
 +    src/
 +    include/ ​  ​(engine'​s internal files)
 +    api/       ​(doomsday.h,​ dd_share.h, doomsday.def,​ etc.)
 +    defs/      (engine'​s definition files)
 +plugins/
 +    jdoom/ ​    (the games should be just plugins like everything else)
 +        src/
 +        include/
 +        defs/
 +    jheretic/
 +    jhexen/
 +    common/
 +        src/
 +        include/
 +        defs/
 +    dehread/
 +    mapload/
 +    d3d/
 +    opengl/
 +packs/
 +    scripts/ ​  ​(resource pack scripts: "​compile PK3s")
 +    jdrp/
 +    jhrp/
 +    jxrp/
 +    examples/ ​ (examples like shiny surfaces for jHexen map01)
 +    tests/ ​    ​(assorted resource tests)
 +</​code>​
 +
 +What this would mean in practice:
 +
 +  *  All project files, build scripts, and makefiles will need to be revised. (Tedious, but doable.)
 +  *  The modules are nicely separated: no more confusion with jHRP's definition files being under Defs/​jHeretic.
 +  *  The Doomsday [[public_api]] can be separated cleanly into its own directory.
 +  * More resource packs can be included in the official repository. (including data files, also thanks to SVN).
 +  * Games are considered appropriately to be plugins.
 +  * Game definition files are stored under the game's own source directory.
 +  * The runtime directory structure either has to mirror this new structure, or perhaps it would be a good idea to figure out a separate runtime structure optimal for runtime operations under a runtime/ root-level directory. It might look something like this:
 +  ​
 +  runtime/
 +      common/ ​   (common.cfg for settings shared by all; executed last?)
 +      jdoom/ ​    ​(jDoom'​s runtime directory)
 +          bspcache/
 +          demo/
 +          savegame/
 +      jheretic/
 +      jhexen/
 +
 +  * When a binary installation is made, only the runtime directory is needed. (Also a bin/ directory for executables on win32. On the Mac, the executables are in the application bundle. In Unix they are in /​usr/​local/​bin and /​usr/​local/​lib or somesuch place.) Something different has to be done with the definitions,​ though. Maybe even "​runtime/​jdoom/​defs"​ (virtually)?​
 +
 +Something needs to be done to existing resource packs. Maybe just make sure that the old directory locations are supported also.
 +
 +
 +====== See also ======
 +
 +  *  [[http://​deng.sourceforge.net/​blog/?​p=37|Discussion at dengDevs]]
 +  *  [[runtime_directory_structure]]
 +
 +
 +
  
devel/directory_structure.txt · Last modified: 2009-07-12 19:24 (external edit)