Introduction to YaM CLARAty Repository
Terms and Definitions
Target
A target in YaM defines a hardware architecture (e.g. x86, ppc), an operating system (e.g. Linux, VxWorks), and a compiler (e.g. gcc2.95, gcc3.4) that the you will build the source code for. CLARAty maintains build rules for a large number of targets. Only a subset of these targets are actively supported (i.e. you are required to build for prior to checking software in the repository).
Site
A site in YaM defines the environment which specifies the location of the compilers to use in building for a given target. Please note that not all sites support building for all targets. For example, if your institution does not have an installation of VxWorks, all such targets cannot be build at your institution.
Using the YaM build system in CLARAty, you can build the software for multiple targets from the same sandbox. You can also build for multiple target from multiple institutions in the same sandbox.
Module
The CLARAty repository is currently organized as a flat collection of individual modules. Each module represents the smallest reusable collection of CLARAty header and source files. A group of files stored in a module directory can only be used as a unit. A module directory can have a subdirectory tree structure. Modules often depend on other modules. You can get this dependency information from the module database. When you add a module to your CLARAty sandbox, the add script will look up the dependencies of that module and add these to your sandbox.
CLARAty does not use the YaM concept of a package. Packages are not needed since dependency information is computed from the module database.
Currently disabled - each module release has a version consisting of <name>-R<major#>-<minor#>. For instance a particular release version of the matrices module might be matrices-R1-06. For a given module, larger version numbers are newer than smaller version numbers, but the version numbers cannot be compared across modules (bits-R1-05 is newer than matrices-R1-06, for example).
Directory Structure
We won't discuss the entire directory structure of the YaM checkout in this document; see the YaM site for further details. However, we will go over a few basics. All subdirectories are relative to the parent checkout directory.
- src - This is where the CLARAty modules live. The modules are organized in subdirectories under src; each module contains its own version control (cvs). When a build takes place, the generated binaries (*.o, *.so, *.a) are placed in subdirectories in each module directory. So, the static shared library for the sockets code, generated for the ppc-vx5.5-gcc2.95 target would reside in src/sockets/ppc-vx5.5-gcc2.95/libsockets.a
- include -This directory contains symbolic links to header files (*.h) in the module subdirectories. In this way, interfaces provided by one module are visible by other modules in a global location. Subdirectories may also exist here.
- lib -This directory is similar to the include directory, except that it provides links to compiled libraries and shared object of each module. In this way, one module can link against code generated by another module. Since the libraries are target-dependent, this directory contains subdirectories (with the same names as the targets) that contain all object code for the target in question.
- bin -This directory is similar to the library directory, except that it provides links to the binaries of each module. In this way, one can all the generated binaries in the sandbox from a single directory. Since the binaries are target-dependent, this directory contains subdirectories (with the same names as the targets) that contain all object code for the target in question. The actual binaries are stored in their respective module/target_name.
- etc - contains a symbolic link to SiteDefs which contains the makefile system, all the site definitions, host machines that define where targets can be compiled and cross-compiled