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 dengDevs

Now that we are using 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:

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)

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