ViewVC Help

View File | Revision Log | Show Annotations | Root Listing

root/cvsroot/COMP/SCRAM/doc/html/scramintro.html

Comparing COMP/SCRAM/doc/html/scramintro.html (file contents):
Revision 1.2 by williamc, Mon Aug 28 08:40:59 2000 UTC vs.
Revision 1.4 by sashby, Fri Jul 20 12:21:28 2001 UTC

#	Line 11 | Line 11
11		<font color=red>M</font>anagement
12		</center>
13		<hr>
14	+	<h2>Background</h2>
15	+	SCRAM has been developed to enable large, geographically dispersed and
16	+	autonomous groups to work together on software development projects.
17	+	The groups, primarily based in universities and national institutions,
18	+	independently manage their own resources. As such it can be extremely
19	+	difficult or even impossible to impose software process, adequate
20	+	documentation levels and heavy resource requirements - such as dedicating
21	+	entire machines to a single software development project.
22	+	<p>
23	+	The philosophy throughout the SCRAM project is, therefore, to
24	+	encourage good practice by making the intuitive easy and convenient way to do
25	+	things the right way of doing things. Take for example the fact that SCRAM is
26	+	controlled and configured through XML documents. Thus documentation has to
27	+	be kept up to date for SCRAM to even function.
28	+	<p>
29		<h2>What is SCRAM?</h2>
30	<	SCRAM is a tool to support large scale distributed software development.
31	<	At its core it is a Software Environment Manager. Having a well defined
32	<	environment enables many useful features :
30	>	<h3>A Configuration Manager</h3>
31	>	The main task of the SCRAM tool is to ensure that all developers are
32	>	working with the same consistent set of products, libraries, environments
33	>	and source codes.
34	>	<ul>
35	>	<li>External Products Configuration<br>
36	>	A requirement of any SCRAM managed project is an
37	>	explicit statement, in the form of an XML document, of all the underlying
38	>	products and versions of external libraries and other software products
39	>	used. Each product must have a description document to tell SCRAM how
40	>	it is to be used, dependency information, environmental variables,
41	>	default system locations etc. Such description documents can be
42	>	maintained independently of SCRAM and imported into the project by
43	>	SCRAMs built-in url down-loading mechanism.
44	>	<li>Common Configurations<br>
45	>	It is often the case that many projects need to share the same configuration
46	>	in order that they can be inter-operable (e.g. Two applications using the
47	>	same database). SCRAM thus provides a mechanism for importing independently
48	>	maintained configuration documents automatically.
49	>
50	>	<li>Source Code Control<br>
51	>	SCRAM itself is not a code repository but any project must have access to
52	>	one or more such repositories from which it can checkout the appropriate
53	>	code into the appropriate place in the project structure. Currently it
54	>	only supports CVS but this could be easily extended to other repositories
55	>	if required.
56	>
57	>	<li>Environment Control<br>
58	>	The build and runtime environments are built up from the descriptions
59	>	of those required by external products and project specific environment
60	>	description documents.
61	>	</ul>
62	>	<h3>A distribution system</h3>
63	>	SCRAM projects can be 'bootstrapped' from a single document that describes
64	>	its structure and download information of other project documents and
65	>	components.<p>
66	>	From this document SCRAM can construct a copy of a project release. Connected
67	>	to a web browser such as netscape makes "single click" installation possible.
68	>	At present SCRAM is unable to automatically install external components
69	>	although the user can be directed to the correct documentation to do this
70	>	themselves. Binary distribution is not supported as building a distribution
71	>	is seen as a check that all the components of the system have been installed
72	>	properly. This feature could be added if user distributions were required.
73	>
74	>	<h3>A System resource/application interface</h3>
75	>	As no two people are the same, it is often the case that no two machines
76	>	are the same. Products can be installed in different places depending on
77	>	the whims of system administrators, policy makers and system constraints.
78	>	SCRAM matches up the request for a product from a projects configuration
79	>	to the system it is installing the project on. SCRAM does this
80	>	by a number of automated means and if it fails to find a product will prompt
81	>	the user for its location. SCRAM then maintains a database of such system
82	>	information for future reference.
83	>
84	>	<h3>A Build System</h3>
85	>	<ul>
86	>	<li> Abstraction of logical build elements from implementation details
87	>	<li> Associate directory and file structure with build operations
88	>	(e.g. everything in a directory libsrc could be automatically compiled
89	>	into a library ,
90	>	e.g.2 every binary in a directory test could be automatically linked
91	>	with a test utilities library)
92	>	<li> Definition of Classes of build objects.
93	>	e.g A library class can have types such as debug, archive, shared,
94	>	shared debug, profiled etc. Default types can be assigned
95	>	to a class/directory structure but are easy to override on the
96	>	command line.
97	>	<li> Strong environment control. Makes it easy to tweak general rules
98	>	for special cases - something not easy to do in make.
99	>	<li> Abstract dependency specification. You can link in a product by specifying
100	>	its name, SCRAM does the rest taking care of system specifics,
101	>	dependencies etc.
102	>	<li> Module Interfaces can be defined for large software modules to define
103	>	dependencies etc. Other modules can then simply load the interface to use
104	>	the module.
105	>	<li> Compatible with code repositories such as CVS which checkout the file
106	>	with the same date that it was checked in. This is a major flaw in make
107	>	which simply checks to see if a datea > dateb rather than datea != dateb.
108	>	</ul>
109	>
110	>	<h3>A development environment</h3>
111	>	Once a copy of a release is installed and built on a system it can be made
112	>	available for developers by adding it to SCRAMs list of projects.
113	>	Upon selecting an item from this list, a new development area is created
114	>	in which the developer can work independently of everyone else. The
115	>	development area will have the same configuration, environment etc. as
116	>	the base release. It will also automatically use libraries/headers etc.
117	>	from the base release if not rebuilt in the local development area. The
118	>	user is free to use whatever editors and other tools he/she prefers.
119	>
120	>	<h3>Project Isolation</h3>
121	>	SCRAM ensures that an installed release is independent of any other. This
122	>	allows developers to easily switch between projects/versions they might be
123	>	working on even though they may have very different and conflicting
124	>	environment requirements.
125	>
126		<p>
127	+	<h2>Summary</h2>
128		<ul>
129		<li>Project installation with a click on a web page
130		<li>Control of Build Environment, including dependency tracking
131		<li>Fully configurable build operations, including default operations.
132		<li>Abstraction of logical build elements from the implementation details
133		<li>Reuse of configuration management elements between projects.
134	<	<li>Configuration specifications with SGML documents.
134	>	<li>Configuration specifications with XML documents.
135		</ul>
136		<p>
137		<img src=../images/scram.jpg>
#	Line 34 | Line 143 | that you think will make this project be
143		<hr>
144		<table border=1 width=100%>
145		<td align=left>
146	<	<a href=mailto:Christopher.Williams@cern.ch
147	<	>Chris Williams</a>
146	>	<a href=mailto:Shaun.Ashby@cern.ch
147	>	>Shaun Ashby</a>
148		</td>
149		<td align=center>
150		<script language="JavaScript">

Diff Legend

–	Removed lines
+	Added lines
<	Changed lines
>	Changed lines