|Contents | Documentation|
FHS - Filesystem Hieararchy Standard and Parrot
Florian Ragwitz <firstname.lastname@example.org>
Maintainer: Florian Ragwitz Date: 5 Dez 2005 Last Modified: 5 Dez 2005 Number: 0 Version: 1
This document introduces to the FHS, the Filesystem Hierarchy Standard, and how those concern Parrot.
The FHS defines some rules for file and directory placement under UNIX-like operating systems. This supports interoperability of applications, system administration tools, development tools, and scripts as well as greater uniformity of documentation for these systems.
There's a large amount of directories explained in the FHS that are not explained here. The reason for this is that not all of them are concerning Parrot.
Does parrot have things where it makes sense to configure them using a config file? I don't think so.
All temporary files should be placed here. Parrot could use this directory for files that are generated during the compile of parrot code to native executables.
/usr contains is shareable, read-only data. Any information that is host-specific or varies with time is stored elsewhere.
This is the primary directory of executable commands on the system. All executables that are intended to be called directly by the user (i.e. parrot, pdump, disassemble, parrot-debugger, pbc_info, pbg_merge, ...) should go here. The current version number should be appended to the binaries itself and a symlink needs to be created that points from the binary with version number to the normal name of the file without a version. That makes installing more than one version possible.
Executables that are for internal use only are stored elsewhere.
This is where all of the system's general-use include files for the C programming language should be placed.
For parrot this is the content of include/parrot. It should be placed in /usr/include/parrot/$(VERSION (i.e. /usr/include/parrot/0.4.0), including those files in include/parrot that are generated during build time.
/usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or scripts.
This is libparrot$(SOEXT).$(SOVERSION) if the parrot binary was linked dynamically. Otherwise nothing.
Also Parrot usees a single subdirectory called /usr/lib/parrot to store all architecture-dependent data exclusively used by parrot. These files are grouped by the parrot version they belong to. So we'll have /usr/lib/parrot/0.4.0, /usr/lib/parrot/0.4.1, etc.
All .pbc and .fpmc files should go there.
.pbc files are kind of architecture independent, because parrot can run PBCs created on any architecture on any architecture, but because .pbc files created on 32 bit platforms differ from those created on 64 bit platforms and the performance of executing bytecode created on an architecture with another address width is much slower we consider parrot bytecode to be architecture dependent.
The /usr/share hierarchy is for all read-only architecture independent data files. Parrot stores those files in /usr/share/parrot/$(VERSION). For example all .pasm and .pir files should go there as well as data files for libraries like images and such.
Manpages are read-only architecture independent data files as well, but they belong into /usr/share/man instead of /usr/share/parrot/ so they are in $MANPATH and can be viewed using the man command.
All documentation as well as examples should go into a subdirectory of /usr/share/doc.
FHS 2.3 - http://www.pathname.com/fhs/