Object Directory Information for Older C Objects (Siemens and Space)
This document describes the "previous" object directory organization in terms of its subdirectories, and what they contain. This organization is used on the Siemens programs and space, where we actually have a single base version of the program, and faulty versions that are derivatives of that base version.
In general, any directory or subdirectory that contains files whose function may not be obvious, or that depart from naming schemes, should contain a CONTENTS file describing those files. We've tried to indicate below where such files might be most desired.
The subdirectories of an object are as follows:
- source.alt
Source.alt contains "variants" of the source code of the base version, each in a subdirectory. Variants are needed when, say, we have to modify the code to accomodate some tool. (They aren't the same as "versions", which truly are new versions of the program and are semantically different.)
The basic variant, that any object will have, is contained in the following subdirectory:
source.orig
This contains the .c file and .h files needed to build the object, plus Makefiles if needed, and subdirectories of any required non-system libraries. (Note that for our objects, all code is coalesced into a single C file; this is explained further in step 5 of the C object handbook).
- source
An empty directory. During experiments, a version of a program that we're working with is placed in here, then deleted after we're finished with it.
- versions.alt
Contains "variants" of the source code of the versions of the program. Variants, as in source.alt, are needed when, say, we have to modify the code to accomodate some tool.
The basic variant, that any object will have, is contained in the subdirectory of versions.alt called:
versions.orig
This directory contains subdirectories
v1, v2, v3, vK
up to some K.
The base version is understood to be in source.alt, and the vJ versions are derivatives of it.
Each vK area contains the .c file and .h files needed to build the version, and subdirectories of any required non-system libraries.
CONTENTS files should describe the reasons for other variants.
- versions
An empty directory, used during some experiments to hold either a version, or a directory of versions, used in the experiment.
- testplans.alt
Testing information for objects.
This directory contains subdirectories v0, v1, ... vK, each of which contains testing information for that version.
Some files that may be present either in this directory or in its vJ subdirectories are:
- universe files (with filenames universe.????; universe.tsl and universe.cov are typical possibilities)
- test suite directories (containing multiple test suites, typically these just contain a subset of the lines in some universe files) these may be tarred and gzipped due to size
CONTENTS files should be provided, especially to distinguish the different tsl specs and universe files
- testplans
An empty directory, used during some experiments to hold test suites needed by that experiment.
- traces.alt
Contains subdirectories v0, v1, ... vK for the versions of the object; these subdirectories can hold trace files and test histories. CONTENTS files are probably necessary. Test history files have the following naming conventions: if a test history file was generated on version vK using the universe.xxx from the version vJ, it will be stored under vK and named <type>th.xxx.vJ, where <type> is 's' for statement trace or 'b' for branch trace.
- traces
An empty directory, used during some experiments to hold traces.
- inputs
Files containing inputs or startup directories used by programs in various tests. These could be grouped into subdirectories or distinguished by naming conventions if helpful, in which case a CONTENTS file would help.
- outputs.alt
Provides a place to permanently store the outputs of test runs, especially when wanting to do regression testing where outputs are diffed with previous outputs.
Could contain subdirectories v0, v1, ... vK to differentiate between versions. Use CONTENTS files to state what is present.
- outputs
An empty directory, used during some experiments to hold test outputs.
- docs
Documentation about the object. Use any subdirectories that are useful. Possibly, v0, v1, ... vK directories will help. Provide a CONTENTS file.
- originals
Original materials obtained on the objects. Use any subdirectories, (e.g. v0, v1, ... vK) that are useful and provide a CONTENTS file. Tarring and gzipping contents is probably worthwhile.
- scripts
The directory from which experiments are run. This directory may also contain saved scripts, such as runall.sh and gettraces.sh scripts that run all tests in the universe. Subdirectories can be used if helpful (e.g. v0, v1, ... vK containing scripts for each version). Provide CONTENTS file.
- info
Other information about the program, especially information gathered by analysis tools and requiring saving for experiments. Use subdirectories as helpful and provide CONTENTS file.
Most likely, there will be subdirectories v0, v1, ... vK here, with each one possibly containing a fault matrix, fault index information, versions matrix, a sensitivity matrix for that version.