User Tools

Site Tools


devel:directory_structure
no way to compare when less than two revisions

Differences

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


devel:directory_structure [2009-07-12 16:24] (current) – created - external edit 127.0.0.1
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 16:24 by 127.0.0.1