The FSW group's approach to the software development process should be reasonably familiar to most C/Unix programmers. The main differences lie in some specialized tools and the associated directory-layout conventions. Both of these are covered in detail by other tutorials; this page merely gives a quick introduction to some key concepts and terminology.

File Management

The FSW source code is maintained in and backed up from a Concurrent Versions System (CVS) archive. Read-only snapshots of the code are fetched from the archive into highly-structured public directory trees (see The FSW File Tree for details), where the production binaries are built.

Although these snapshots provide the group's common code base, they are rarely accessed directly by developers. Instead, each developer works on private copies of the code, checking in new versions when appropriate. These copies are maintained in CMX "playpens", as:

   .../
   | $package/   public interface (header files, etc.)
   | doc/        Traveler docs (e.g., manuals)
   | ptd/        package test directory
   | | LTX/      LTX control files
   | sdf/        diagrams, logs, notes, ...
   | src/        where the private source goes
    

Most of these files and directories are of no direct interest to the developer. S/he edits and tests the source code, using CMX to "fetch" the code, "build" the binaries and documentation, "commit" the code for public access, etc. CMX, in turn, invokes the Code Management Tool (CMT), which may bring in any of several other tools: CVS, Doxygen, GCC, Graphviz, etc.

As a useful side-effect of the build process, a substantial amount of documentation is created. Integrating the developer's (specially-formatted) comments with mechanically-harvested metadata, Doxygen creates textual descriptions, tables, and even diagrams (via Graphviz) of key relationships.

Note: Some of these diagrams take a substantial amount of time to create. In order to conserve the developers' time, these are only "scheduled" during the build process. Early the next morning, the diagrams are created (along with the rest of the FSW group's mechanically-generated documentation). Immediate access to the complete set of diagrams is available, if desired, via the CMX "--doxygen=full" option.

Computer Facilities

The interactive tools described above can, in theory, be run on almost any Unix-like system. They are known to run on Linux and Solaris. They are currently being ported to Cygwin and a port to Mac OS X has been discussed. They are currently being run on SLAC's Linux and Solaris servers, as well as some "desktop" and "lab" machines at SLAC and NRL.

Note: Although the nightly documentation scripts are mostly written in Perl (and hence, quite portable), little effort has been made to port them to any environment other than the Solaris-based trscrontab facility provided by SLAC.

The generated code can usually be run on the build machine, although access to some hardware interfaces may have to be simulated. The major exceptions to this rule are stringent dependencies on specialized add-on hardware, the PowerPC processor architecture, and Tornado (the VxWorks IDE).

In short, most developers can build and perform initial tests on their binaries, using generic Unix-like machines. When access to a VxWorks machine is needed, the developer will need to reserve access time on one or more of the available PowerPC "crates". Tornado provides an advisory locking mechanism for access to a given machine; this helps to keep developers from interfering with each others' tests.

The Development Process

Initially, the developer must gain access to the development machine(s), install and configure any favorite tools, etc. Once this has been done, s/he is (almost) ready to start developing code. The remaining detail, however, is where to do the work.

In order to use CMX, the developer will need to create a private development area, or "playpen". Fortunately, CMX does most of the work here. See the CMX tutorial for details.

Once the needed directories are in place, the developer will follow a fairly conventional edit / build / test cycle. Because CMX is used to manage the "build" step, the developer does not need to worry about getting the correct versions of other packages, building for the right target environment, etc.

When the developer has something that is ready for others to try out, s/he will typically create a "development" version. When the code is deemed to be trustworthy, s/he will upgrade it to "production" status. By managing a great deal of detail (see the Build Matrix), CMX allows developers to develop interrelated subsystems without falling prey to "deadlocks" or unreliable code.