| 1 |
sashby |
1.1 |
%%____________________________________________________________________
|
| 2 |
|
|
%% File: Introduction.tex
|
| 3 |
|
|
%%____________________________________________________________________
|
| 4 |
|
|
%%
|
| 5 |
|
|
%% Author: Shaun ASHBY <Shaun.Ashby@cern.ch>
|
| 6 |
|
|
%% Update: 2005-11-02 17:04:04+0100
|
| 7 |
|
|
%% Revision: $Id$
|
| 8 |
|
|
%%
|
| 9 |
|
|
%% Copyright: 2005 (C) Shaun ASHBY
|
| 10 |
|
|
%%
|
| 11 |
|
|
%%--------------------------------------------------------------------
|
| 12 |
|
|
\chapter{Introduction}\label{ch:intro}
|
| 13 |
|
|
\index{Introduction}
|
| 14 |
|
|
\scram\ has been developed to enable large, geographically dispersed
|
| 15 |
|
|
and autonomous groups to work together on software development
|
| 16 |
|
|
projects. The groups, primarily based in universities and academic
|
| 17 |
|
|
institutions, independently manage their own resources. As such it can
|
| 18 |
|
|
be extremely difficult or even impossible to impose software process,
|
| 19 |
|
|
adequate documentation levels and heavy resource requirements - such
|
| 20 |
|
|
as dedicating entire machines to a single software development
|
| 21 |
|
|
project.
|
| 22 |
|
|
|
| 23 |
|
|
\section{What is SCRAM?}\index{SCRAM!What is SCRAM?}
|
| 24 |
|
|
|
| 25 |
|
|
\scram\ is a configuration management tool, a distribution system, a
|
| 26 |
|
|
build system and resource manager, with local resources and
|
| 27 |
|
|
applications managed in a transparent way. In addition it provides a
|
| 28 |
|
|
common development environment. These features are described more
|
| 29 |
|
|
fully below.
|
| 30 |
|
|
|
| 31 |
|
|
\subsection{Configuration Management}\label{sec:cm}
|
| 32 |
|
|
\index{SCRAM!configuration management}
|
| 33 |
|
|
The main task of \scram\ is to ensure that all developers are working
|
| 34 |
|
|
with the same consistent set of external products, libraries,
|
| 35 |
|
|
environments and source codes. Configuration management methods ensure
|
| 36 |
|
|
that this is possible.
|
| 37 |
|
|
\begin{description}
|
| 38 |
|
|
\item [\textsc{external products configuration}]\mbox{}\\
|
| 39 |
|
|
A requirement of any \scram\ managed project is an explicit
|
| 40 |
|
|
statement, in the form of a special-purpose document, of all
|
| 41 |
|
|
underlying products and versions of external libraries and other
|
| 42 |
|
|
software products used. Each product must have a description
|
| 43 |
|
|
document to inform \scram\ how it is to be used, to supply dependency
|
| 44 |
|
|
information, set environmental variables, and give default system
|
| 45 |
|
|
locations. Such description documents can be maintained
|
| 46 |
|
|
independently of \scram\ and imported into the project by
|
| 47 |
|
|
\scram's built-in URL downloading mechanism.
|
| 48 |
|
|
\item[\textsc{common configurations}]\mbox{}\\
|
| 49 |
|
|
It is often the case that many projects need to share the same
|
| 50 |
|
|
configuration in order that they can be inter-operable (\eg two
|
| 51 |
|
|
applications using the same database). \scram\ thus provides a
|
| 52 |
|
|
mechanism for importing independently maintained configuration
|
| 53 |
|
|
documents automatically.
|
| 54 |
|
|
\item[\textsc{source code control}]\mbox{}\\
|
| 55 |
|
|
\scram\ itself is not a code repository. Any project must have
|
| 56 |
|
|
access to one or more such repositories from which it can checkout
|
| 57 |
|
|
the appropriate code into the appropriate place in the project
|
| 58 |
|
|
structure. Currently, CVS is used for all source code management.
|
| 59 |
|
|
Both source code and project configuration files are tagged with a
|
| 60 |
|
|
CVS symbolic tag when ready for release.
|
| 61 |
|
|
\item[\textsc{environment control}]\mbox{}\\
|
| 62 |
|
|
The build and runtime environments are constructed automatically
|
| 63 |
|
|
from the description documents of the required external products and
|
| 64 |
|
|
the project-specific environment.
|
| 65 |
|
|
\end{description}
|
| 66 |
|
|
|
| 67 |
|
|
|
| 68 |
|
|
\subsection{The Distribution System}\label{sec:dist}
|
| 69 |
|
|
\index{SCRAM!distribution system}
|
| 70 |
|
|
\index{bootstrapping}
|
| 71 |
|
|
\scram\ projects can be `bootstrapped' from a single description
|
| 72 |
|
|
document in which the structure and download information of other
|
| 73 |
|
|
required project documents and components is declared.
|
| 74 |
|
|
|
| 75 |
|
|
\ni From this document \scram\ can construct a copy of a project release.
|
| 76 |
|
|
Connected to a properly configured web browser such as Netscape makes
|
| 77 |
|
|
automatic project installation possible. At present, \scram\ is unable
|
| 78 |
|
|
to automatically install external components although the user can be
|
| 79 |
|
|
directed to the correct documentation to enable him/her to do this.
|
| 80 |
|
|
Binary distribution is not supported as building a distribution is
|
| 81 |
|
|
seen as a check that all the components of the system have been
|
| 82 |
|
|
installed properly. Other tools, compatible with \scram\, are available
|
| 83 |
|
|
to produce binary distributions from project releases.
|
| 84 |
|
|
|
| 85 |
|
|
\subsection{A System Resource/Application Interface}\label{sec:resource}
|
| 86 |
|
|
\index{SCRAM!resource manager}
|
| 87 |
|
|
\index{SCRAM!application interface}
|
| 88 |
|
|
Often, machines are not installed with the various products in the
|
| 89 |
|
|
same directories, their locations decided upon by system
|
| 90 |
|
|
administrators or system constraints (sizes of filesystems, for
|
| 91 |
|
|
example). Install locations can also vary from platform to platform.
|
| 92 |
|
|
\scram\ matches up the request for a product in a project configuration
|
| 93 |
|
|
to the system it is installing the project on. Automated means are
|
| 94 |
|
|
used to achieve this but the user will be prompted if a product cannot
|
| 95 |
|
|
be found. The user also can have full interactive control of these
|
| 96 |
|
|
setup stages if preferred.
|
| 97 |
|
|
|
| 98 |
|
|
\ni A database of system information is maintained by \scram\ for
|
| 99 |
|
|
future reference in each project area.
|
| 100 |
|
|
|
| 101 |
|
|
\subsection{A Build System}\label{sec:bs}
|
| 102 |
|
|
\index{SCRAM!build system}
|
| 103 |
|
|
The build system can be used to build shared or archive libraries,
|
| 104 |
|
|
plug-in modules, binaries or additional libraries (for a test suite,
|
| 105 |
|
|
for example). The configuration documents within the project area
|
| 106 |
|
|
describe the actions to be taken during the build process. These
|
| 107 |
|
|
actions can be global, or specific to parts of the source directory
|
| 108 |
|
|
tree structure. (\eg everything in a directory \texttt{libsrc} could
|
| 109 |
|
|
be automatically compiled into a library or every binary in a
|
| 110 |
|
|
directory called \texttt{test} could be automatically linked with a
|
| 111 |
|
|
test utilities library).
|
| 112 |
|
|
\index{available library classes}
|
| 113 |
|
|
\ni Classes of build objects can be defined: for example, a library class
|
| 114 |
|
|
can have types such as {\em debug}, {\em archive}, {\em shared}, {\em
|
| 115 |
|
|
shared debug}, \etc Default types can be assigned to a
|
| 116 |
|
|
class/directory structure but can be easily overriden.% with options
|
| 117 |
|
|
%from the command line.
|
| 118 |
|
|
The environment can be easily tuned for
|
| 119 |
|
|
special cases by simply modifying the templates defining the general
|
| 120 |
|
|
rules. The dependencies are specified in an abstract manner. Extra
|
| 121 |
|
|
external products to be included during linking can be referred to
|
| 122 |
|
|
by name with \scram\ taking care of the system specifics.
|
| 123 |
|
|
\index{module interfaces}
|
| 124 |
|
|
\ni Module interfaces can be defined for large software modules to define
|
| 125 |
|
|
dependencies \etc Other modules can then simply load the interface to
|
| 126 |
|
|
use the module.
|
| 127 |
|
|
|
| 128 |
|
|
\subsection{A Development Environment}\label{sec:de}
|
| 129 |
|
|
\index{SCRAM!development environment}
|
| 130 |
|
|
Once a copy of a project is installed and built on a particular
|
| 131 |
|
|
platform it can be made publicly available (\ie {\em released}) for developers
|
| 132 |
|
|
by adding it to \scram's list of projects (the project database).
|
| 133 |
|
|
|
| 134 |
|
|
\ni Upon selecting an item from this list, a new development area is
|
| 135 |
|
|
created in which the developer can work independently of everyone
|
| 136 |
|
|
else. The development area will have the same configuration and
|
| 137 |
|
|
environment as the base release. It will also automatically use
|
| 138 |
|
|
libraries and headers from the base release if not rebuilt in the
|
| 139 |
|
|
local development area.
|
| 140 |
|
|
|
| 141 |
|
|
\subsection{Project Isolation}
|
| 142 |
|
|
\index{SCRAM!project isolation}
|
| 143 |
|
|
\scram\ ensures that an installed release is independent of any other.
|
| 144 |
|
|
This allows developers to easily switch between projects/versions they
|
| 145 |
|
|
might be working on even though they may have very different and
|
| 146 |
|
|
conflicting environment requirements.
|
| 147 |
|
|
%%
|
| 148 |
|
|
\index{SCRAM!overview}
|
| 149 |
|
|
\begin{latexonly}
|
| 150 |
|
|
\begin{figure}[ht]
|
| 151 |
|
|
\begin{center}
|
| 152 |
|
|
\leavevmode \epsfig{file=images/scram.eps, width=\linewidth}
|
| 153 |
|
|
\caption[A SCRAM overview.]
|
| 154 |
|
|
{A SCRAM overview.}
|
| 155 |
|
|
\label{f:SCRAM}
|
| 156 |
|
|
\end{center}
|
| 157 |
|
|
\end{figure}
|
| 158 |
|
|
\end{latexonly}
|
| 159 |
|
|
|
| 160 |
|
|
\ni In summary, \scram\ can provide
|
| 161 |
|
|
\begin{itemize}
|
| 162 |
|
|
\item project installation with a click on a web page;
|
| 163 |
|
|
\item control of the build environment, including dependency tracking;
|
| 164 |
|
|
\item fully configurable build operations, including default operations;
|
| 165 |
|
|
\item abstraction of logical build elements from the implementation details;
|
| 166 |
|
|
\item re-use of configuration management elements between projects.
|
| 167 |
|
|
\end{itemize}
|
| 168 |
|
|
|
| 169 |
|
|
|
| 170 |
|
|
\section{The Structure of This Guide}
|
| 171 |
|
|
|
| 172 |
|
|
This document can be broken down as follows: firstly,
|
| 173 |
|
|
Chapter~\ref{ch:install} gives some details on how to obtain \scram\
|
| 174 |
|
|
and instructions on how to create a local installation.
|
| 175 |
|
|
Chapter~\ref{ch:creatingprojects} contains all information necessary for
|
| 176 |
|
|
administrators (or users wanting to use \scram\ privately) to
|
| 177 |
|
|
create new projects using \scram\ as the management tool, and to
|
| 178 |
|
|
maintain them. The various types of project configuration files, and
|
| 179 |
|
|
the purposes of each (with use cases), are also described.
|
| 180 |
|
|
Chapter~\ref{ch:examples} serves as a resource for developers who
|
| 181 |
|
|
use \scram\ in their environment, providing some examples and tips covering topics
|
| 182 |
|
|
like changing tool configurations or adding new external tools in a
|
| 183 |
|
|
private area.
|
| 184 |
|
|
|
| 185 |
|
|
\ni Finally there is a summary page containing help for usage for all of
|
| 186 |
|
|
the currently supported \scram\ commands (p~\pageref{ch:quickhelpguide}).
|
| 187 |
|
|
|
| 188 |
|
|
\newpage % Start on a fresh page
|
| 189 |
|
|
|
| 190 |
|
|
%%% Local Variables:
|
| 191 |
|
|
%%% mode: latex
|
| 192 |
|
|
%%% TeX-master: "SCRAM-manual"
|
| 193 |
|
|
%%% End:
|
| 194 |
|
|
|
| 195 |
|
|
%%____________________________________________________________________
|
| 196 |
|
|
%% End of Introduction.tex
|
| 197 |
|
|
%%____________________________________________________________________
|
| 198 |
|
|
%%
|
