Planet

navi

home

PPS

about

screenshots

download

development

forum

Context Navigation

source: downloads/boost_1_33_1/tools/build/jam_src/Jam.html @ 12

Last change on this file since 12 was 12, checked in by landauf, 18 years ago
added boost
File size: 40.9 KB

Line
1	<HTML>
2
3	<TITLE> Jam/MR - Make(1) Redux </TITLE>
4
5	<BODY>
6
7	<CENTER>
8
9	<H1> Jam/MR - Make(1) Redux </H1>
10
11	<P> The <a href=http://www.perforce.com/jam/jam.html>Jam/MR</a> Executable
12
13	</CENTER>
14
15	<DL>
16
17	<DT> <P> <H2> USAGE </H2> <DD>
18
19	<PRE>
20	jam [ -a ] [ -n ] [ -v ] [ -q ]
21	[ -d <I>debug</I> ]
22	[ -f <I>jambase</I> ]
23	[ -j <I>jobs</I> ]
24	[ -o <I>actionsfile</I> ]
25	[ -s <I>var</I>=<I>value</I> ]
26	[ -t <I>target</I> ]
27	[ <I>target</I> ... ]
28	</PRE>
29
30	<DT> <P> <H2> DESCRIPTION </H2> <DD>
31
32	<P>
33
34	<B>Jam</B> is a program construction tool, like <B>make</B>(1).
35
36	<P>
37
38	<B>Jam</B> recursively builds target files from source files,
39	using dependency information and updating actions expressed in
40	the Jambase file, which is written in <B>jam</B>'s own interpreted
41	language. The default Jambase is compiled into <B>jam</B> and
42	provides a boilerplate for common use, relying on a user-provide
43	file "Jamfile" to enumerate actual targets and sources.
44
45	<P>
46
47	The Jambase is described in the <a href="Jambase.html">Jambase
48	Reference</a> and the document <a href="Jamfile.html">Using
49	Jamfiles and Jambase</A>.
50
51	<DT> <P> <H2> OPTIONS </H2> <DD>
52
53	<P>
54
55	If <I>target</I> is provided on the command line, <B>jam</B>
56	builds <I>target;</I> otherwise <B>jam</B> builds the target
57	'all'.
58
59	<P>
60
61	<B>Jam</b> may be invoked with the following options:
62
63	<P> <TABLE WIDTH=75% ALIGN=CENTER>
64
65	<TR><TD VALIGN=TOP><CODE> -a </CODE>
66	<TD> Build all targets anyway, even if they are up-to-date.
67
68	<TR><TD VALIGN=TOP><CODE> -d <I>n</I> </CODE>
69	<TD> Enable cummulative debugging levels from 1 to <I>n</I>.
70	Interesting values are:
71
72	<DL COMPACT>
73	<DT> 1 <DD> Show actions (the default)
74	<DT> 2 <DD> Show "quiet" actions and display all action text
75	<DT> 3 <DD> Show dependency analysis, and target/source
76	timestamps/paths
77	<DT> 4 <DD> Show shell arguments
78	<DT> 5 <DD> Show rule invocations and variable expansions
79	<DT> 6 <DD> Show directory/header file/archive scans
80	<DT> 7 <DD> Show variable settings
81	<DT> 8 <DD> Show variable fetches
82	<DT> 9 <DD> Show variable manipulation, scanner tokens
83	</DL>
84
85	<TR><TD VALIGN=TOP><CODE> -d +<I>n</I> </CODE>
86	<TD> Enable debugging level <I>n</I>.
87
88	<TR><TD VALIGN=TOP><CODE> -d 0 </CODE>
89	<TD> Turn off all debugging levels. Only errors are not suppressed.
90
91	<TR><TD VALIGN=TOP><CODE> -f <I>jambase</I></CODE>
92	<TD>Read <I>jambase</I> instead of using the built-in Jambase.
93	Only one -f flag is permitted, but the <i>jambase</i> may
94	explicitly include other files.
95
96	<TR><TD VALIGN=TOP><CODE> -j <I>n</I></CODE>
97	<TD> Run up to <I>n</I> shell commands concurrently (UNIX
98	and NT only). The default is 1.
99
100	<TR><TD VALIGN=TOP><CODE> -n</CODE>
101	<TD> Don't actually execute the updating actions, but do
102	everything else. This changes the debug level default to -d2.
103
104	<TR><TD VALIGN=TOP><CODE> -o <I>file</I></CODE>
105	<TD> Write the updating actions to the specified file instead
106	of running them (or outputting them, as on the Mac).
107
108	<TR><TD VALIGN=TOP><CODE> -q </CODE>
109	<TD> Quit quickly (as if an interrupt was received)
110	as soon as any target fails.
111
112	<TR><TD VALIGN=TOP><CODE> -s <I>var</I>=<I>value</I></CODE>
113	<TD> Set the variable <I>var</I> to <I>value</I>, overriding
114	both internal variables and variables imported from the
115	environment.
116
117	<TR><TD VALIGN=TOP><CODE> -t <I>target</I></CODE>
118	<TD> Rebuild <I>target</I> and everything that depends on it,
119	even if it is up-to-date.
120
121	<TR><TD VALIGN=TOP><CODE> -v</CODE>
122	<TD> Print the version of <B>jam</B> and exit.
123
124	</TABLE>
125
126	<DT> <P> <H2> OPERATION </H2> <DD>
127
128	<P>
129
130	<b>Jam</b> has four phases of operation: start-up, parsing,
131	binding, and updating.
132
133	<DT> <P> <H3> Start-up </H3> <DD>
134
135	<P>
136
137	Upon start-up, <b>jam</b> imports environment variable settings
138	into <b>jam</b> variables. Environment variables are split at
139	blanks with each word becoming an element in the variable's list
140	of values. Environment variables whose names end in PATH are
141	split at $(SPLITPATH) characters (e.g., ":" for Unix).
142
143	<P>
144
145	To set a variable's value on the command line, overriding the
146	variable's environment value, use the -s option. To see variable
147	assignments made during <b>jam</b>'s execution, use the -d+7
148	option.
149
150	<DT> <P> <H3> Parsing </H3> <DD>
151
152	<P>
153
154	In the parsing phase, <b>jam</b> reads and parses the Jambase
155	file, by default the built-in one. It is written in the <b>jam</b>
156	language. See <a href="#language"> Language</a> below. The
157	last action of the Jambase is to read (via the "include" rule)
158	a user-provided file called "Jamfile".
159
160	<P>
161
162	Collectively, the purpose of the Jambase and the Jamfile is to
163	name built target and source files, construct the dependency
164	graph among them, and associate build actions with targets.
165	The Jambase defines boilerplate rules and variable assignments,
166	and the Jamfile uses these to specify the actual relationship
167	among the target and source files. See the <a
168	href="Jambase.html">Jambase Reference</a> and the document <a
169	href="Jamfile.html">Using Jamfiles and Jambase</A> for information.
170
171	<A NAME="binding">
172	<DT> <P> <H3> Binding </H3> <DD>
173	</A>
174
175	<P>
176
177	<P> <H5> Binding </H5>
178
179	After parsing, <B>jam</B> recursively descends the dependency
180	graph and binds every file target with a location in the
181	filesystem. If <B>jam</B> detects a circular dependency in the
182	graph, it issues a warning.
183
184	<P>
185
186	File target names are given as absolute or relative path names
187	in the filesystem. If the path name is absolute, it is bound
188	as is. If the path name is relative, it is normally bound as
189	is, and thus relative to the current directory. This can be
190	modified by the settings of the $(SEARCH) and $(LOCATE) variables,
191	which enable <b>jam</b> to find and build targets spread across
192	a directory tree. See <A HREF="#search">SEARCH and LOCATE
193	Variables</a> below.
194
195	<P> <H5> Update Determination </H5>
196
197	After binding each target, <B>jam</B> determines whether the
198	target needs updating, and if so marks the target for the updating
199	phase. A target is normally so marked if it is missing, it is
200	older than any of its sources, or any of its sources are marked
201	for updating. This behavior can be modified by the application
202	of special built-in rules, ALWAYS, LEAVES, NOCARE, NOTFILE,
203	NOUPDATE, and TEMPORARY. See <A HREF="#bindingmods">Modifying
204	Binding</A> below.
205
206	<P> <H5> Header File Scanning </H5>
207
208	<P>
209
210	During the binding phase, <b>jam</b> also performs header file
211	scanning, where it looks inside source files for the implicit
212	dependencies on other files caused by C's #include syntax. This
213	is controlled by the special variables $(HDRSCAN) and $(HDRRULE).
214	The result of the scan is formed into a rule invocation, with
215	the scanned file as the target and the found included file names
216	as the sources. Note that this is the only case where rules
217	are invoked outside the parsing phase. See <A
218	HREF="#hdrscan">HDRSCAN and HDRRULE Variables</A> below.
219
220	<DT> <P> <H3> Updating </H3> <DD>
221
222	<P>
223
224	After binding, <B>jam</B> again recursively descends the dependency
225	graph, this time executing the update actions for each target
226	marked for update during the binding phase. If a target's
227	updating actions fail, then all other targets which depend on
228	that target are skipped.
229
230	<P>
231
232	The -j flag instructs <B>jam</B> to build more than one target
233	at a time. If there are multiple actions on a single target,
234	they are run sequentially.
235
236	<A NAME="language">
237	<DT> <P> <H2> LANGUAGE </H2> <DD>
238	</A>
239
240	<DT> <P> <H3> Overview </H3> <DD>
241
242	<B>Jam</b> has an interpreted, procedural language. Statements
243	in <b>jam</b> are rule (procedure) definitions, rule invocations,
244	flow-of-control structures, variable assignments, and sundry
245	language support.
246
247	<DT> <P> <H3> Lexical Features </H3> <DD>
248
249	<P>
250
251	<B>Jam</b> treats its input files as whitespace-separated tokens,
252	with two exceptions: double quotes (") can enclose whitespace
253	to embed it into a token, and everything between the matching
254	curly braces ({}) in the definition of a rule action is treated
255	as a single string. A backslash (\) can escape a double quote,
256	or any single whitespace character.
257
258	<P>
259
260	<B>Jam</b> requires whitespace (blanks, tabs, or newlines) to
261	surround all tokens, <i>including the colon (:) and semicolon
262	(;) tokens</i>.
263
264	<P>
265
266	<B>Jam</b> keywords (an mentioned in this document) are reserved
267	and generally must be quoted with double quotes (") to be used
268	as arbitrary tokens, such as variable or target names.
269
270	<DT> <P> <H3> Targets </H3> <DD>
271
272	<P>
273
274	The essential <b>jam</b> data entity is a target. Built targets
275	are files to be updated. Source targets are the files used in
276	updating built targets. Built targets and source targets are
277	collectively referred to as file targets, and frequently built
278	targets are source targets for other built targets. Pseudotargets
279	are symbols which represent dependencies on other targets, but
280	which are not themselves associated with any real file.
281
282	<P>
283
284	A file target's identifier is generally the file's name, which
285	can be absolutely rooted, relative to the directory of <b>jam</b>'s
286	invocation, or simply local (no directory). Most often it is
287	the last case, and the actual file path is bound using the
288	$(SEARCH) and $(LOCATE) special variables. See <A HREF="#search">
289	SEARCH and LOCATE Variables</A> below. A local filename is
290	optionally qualified with grist, a string value used to assure
291	uniqueness. A file target with an identifier of the form
292	<I>file(member)</I> is a library member (usually an ar(1) archive
293	on UNIX).
294
295	<DT> <P> <H3> Rules </H3> <DD>
296
297	<P>
298
299	The basic <B>jam</b> language entity is called a rule. A rule
300	is defined in two parts: the procedure and the actions. The
301	procedure is a body of <b>jam</b> statements to be run when the
302	rule is invoked; the actions are the OS shell commands to execute
303	when updating the built targets of the rule.
304
305	<P>
306
307	Rules can return values, which can be expanded into a list with
308	"[ <i>rule</i> <i>args</i> ... ]". A rule's value is the value
309	of its last statement, though only the following statements
310	have values: 'if' (value of the leg chosen), 'switch' (value of the case
311	chosen), set (value of the resulting variable), and 'return' (value
312	of its arguments). Note that 'return' doesn't actually cause a
313	return, i.e., is a no-op unless it is the last statement
314	of the last block executed within rule body.
315
316	<P>
317
318	The <b>jam</b> statements for defining and invoking rules are
319	as follows:
320
321	<P><TABLE WIDTH=75% ALIGN=CENTER><TR><TD><DL>
322
323	<P> <DT> <CODE>
324	rule <I>rulename</I> { <I>statements</I> }
325	</CODE>
326
327	<DD> Define a rule's procedure, replacing any previous
328	definition.
329
330	<P> <DT> <CODE>
331	actions [ <I>modifiers</I> ] <I>rulename</I> { <I>commands</I> }
332	</CODE>
333
334	<DD> Define a rule's updating actions, replacing any
335	previous definition.
336
337	<P> <DT> <CODE>
338	<I>rulename field1</I> : <I>field2</I> : <I>...</I>
339	: <I>fieldN</I> ;
340	</CODE>
341
342	<DD> Invoke a rule.
343
344	<P> <DT> <CODE>
345	on <I>target</I> <I>rulename field1</I> : <I>field2</I> : <I>...</I>
346	: <I>fieldN</I> ;
347	</CODE>
348
349	<DD> Invoke a rule under the influence of <I>target</I>'s specific
350	variables..
351
352	<P> <DT> <CODE>
353	[ <I>rulename field1</I> : <I>field2</I> : <I>...</I>
354	: <I>fieldN</I> ] <br>
355	[ on <I>target</I> <I>rulename field1</I> : <I>field2</I> : <I>...</I>
356	: <I>fieldN</I> ] <br>
357
358	</CODE>
359
360	<DD> Used as an argument, expands to the return value of the rule invoked.
361
362	</DL></TABLE>
363
364	<P>
365
366	A rule is invoked with values in <I>field1</I> through
367	<I>fieldN</I>. They may be referenced in the procedure's
368	<I>statements</I> as $(1) through $(<I>N</I>) (9 max), and the
369	first two only may be referenced in the action's <I>commands</I>
370	as $(1) and $(2). $(<) and $(>) are synonymous with $(1)
371	and $(2).
372
373	<P>
374
375	Rules fall into two categories: updating rules (with actions),
376	and pure procedure rules (without actions). Updating rules
377	treat arguments $(1) and $(2) as built targets and sources,
378	respectively, while pure procedure rules can take arbitrary
379	arguments.
380
381	<P>
382
383	When an updating rule is invoked, its updating actions are added
384	to those associated with its built targets ($(1)) before the
385	rule's procedure is run. Later, to build the targets in the
386	updating phase, <I>commands</I> are passed to the OS command
387	shell, with $(1) and $(2) replaced by bound versions of the
388	target names. See <A HREF="#binding"> Binding</A> above.
389
390	<P>
391
392	Rule invokation may be indirected through a variable:
393
394	<P><TABLE WIDTH=75% ALIGN=CENTER><TR><TD><DL>
395
396	<P> <DT> <CODE>
397	$(<I>var</I>) <I>field1</I> : <I>field2</I> : <I>...</I>
398	: <I>fieldN</I> ;
399	</CODE>
400
401	<P> <DT> <CODE>
402	on <I>target</I> $(<I>var</I>) <I>field1</I> : <I>field2</I> : <I>...</I>
403	: <I>fieldN</I> ;
404	</CODE>
405
406	<P> <DT> <CODE>
407	[ $(<I>var</I>) <I>field1</I> : <I>field2</I> : <I>...</I>
408
409	: <I>fieldN</I> ] <br>
410	[ on <I>target</I> $(<I>var</I>) <I>field1</I> : <I>field2</I> : <I>...</I>
411	: <I>fieldN</I> ] <br>
412
413	</CODE>
414
415	</DL></TABLE>
416
417	The variable's value names the rule (or rules) to be invoked.
418	A rule is invoked for each element in the list of
419	<TT>$(<I>var</I>)</TT>'s values. The fields
420	<I>field1</I> : <I>field2</I> : <I>...</I> are passed as
421	arguments for each invokation. For the <TT> [ ... ] </TT> forms,
422	the return value is the concatenation of the return values for
423	all of the invokations.
424
425	<A NAME="actionmods">
426	<P> <H4> Action Modifiers </H4>
427	</A>
428
429	<P>
430
431	The following action <i>modifiers</i> are understood:
432
433	<P><TABLE WIDTH=75% ALIGN=CENTER><TR><TD><DL>
434
435	<P><DT><CODE> actions bind <I>vars</I> </CODE>
436	<DD> $(vars) will be replaced with bound values.
437
438	<P><DT><CODE> actions existing </CODE>
439	<DD> $(>) includes only source targets currently existing.
440
441	<P><DT><CODE> actions ignore </CODE>
442	<DD> The return status of the <I>commands</I> is ignored.
443
444	<P><DT><CODE> actions piecemeal </CODE>
445	<DD> <I>commands</I> are repeatedly invoked with a subset
446	of $(>) small enough to fit in the command buffer on this
447	OS.
448
449	<P><DT><CODE> actions quietly </CODE>
450	<DD> The action is not echoed to the standard output.
451
452	<P><DT><CODE> actions together </CODE>
453	<DD> The $(>) from multiple invocations of the same action
454	on the same built target are glommed together.
455
456	<P><DT><CODE> actions updated </CODE>
457	<DD> $(>) includes only source targets themselves marked
458	for updating.
459
460	</DL></TABLE>
461
462
463	<DT> <P> <H3> Built-in Rules </H3> <DD>
464
465	<P>
466	<B>Jam</b> has eleven built-in rules, all of which are pure
467	procedure rules without updating actions. They are in
468	three groups: the first builds the dependency graph;
469	the second modifies it; and the third are just utility
470	rules.
471
472	<P>
473
474	<P> <H5> Dependency Building </H5>
475
476	<P><TABLE WIDTH=75% ALIGN=CENTER><TR><TD><DL>
477
478	<P><DT><CODE>
479	DEPENDS <I>targets1</I> : <I>targets2</I> ;
480	</CODE>
481
482	<DD> Builds a direct dependency: makes each of <I>targets1</I>
483	depend on each of <I>targets2</I>. Generally, <I>targets1</I>
484	will be rebuilt if <I>targets2</I> are themselves rebuilt are
485	or are newer than <I>targets1</I>.
486
487	<P><DT><CODE>
488	INCLUDES <I>targets1</I> : <I>targets2</I> ;
489	</CODE>
490
491	<DD> Builds a sibling dependency: makes any target that depends
492	on any of <I>targets1</I> also depend on each of <I>targets2</I>.
493	This reflects the dependencies that arise when one source file
494	includes another: the object built from the source file depends
495	both on the original and included source file, but the two
496	sources files don't depend on each other. For example:
497
498	<CODE>
499	<P>DEPENDS foo.o : foo.c ;
500	<BR>INCLUDES foo.c : foo.h ;
501	</CODE>
502
503	<P>
504
505	"foo.o" depends on "foo.c" and "foo.h" in this example.
506
507	</DL></TABLE>
508
509	<A NAME="bindingmods">
510	<P> <H5> Modifying Binding </H5>
511	</A>
512
513	<P>
514
515	The six rules ALWAYS, LEAVES, NOCARE, NOTFILE, NOUPDATE, and
516	TEMPORARY modify the dependency graph so that <b>jam</b> treats
517	the targets differently during its target binding phase. See
518	<A HREF="#binding">Binding</A> above. Normally, <b>jam</b>
519	updates a target if it is missing, if its filesystem modification
520	time is older than any of its dependencies (recursively), or if
521	any of its dependencies are being updated. This basic behavior
522	can be changed by invoking the following rules:
523
524	<P><TABLE WIDTH=75% ALIGN=CENTER><TR><TD><DL>
525
526	<P><DT><CODE>
527	ALWAYS <I>targets</I> ;
528	</CODE>
529
530	<DD> Causes <I>targets</I> to be rebuilt regardless of whether
531	they are up-to-date (they must still be in the dependency graph).
532	This is used for the clean and uninstall targets, as they have
533	no dependencies and would otherwise appear never to need building.
534	It is best applied to targets that are also NOTFILE targets,
535	but it can also be used to force a real file to be updated as
536	well.
537
538	<P><DT><CODE>
539	LEAVES <I>targets</I> ;
540	</CODE>
541
542	<DD> Makes each of <I>targets</I> depend only on its leaf sources,
543	and not on any intermediate targets. This makes it immune to
544	its dependencies being updated, as the "leaf" dependencies are
545	those without their own dependencies and without updating actions.
546	This allows a target to be updated only if original source files
547	change.
548
549	<P><DT><CODE>
550	NOCARE <I>targets</I> ;
551	</CODE>
552
553	<DD> Causes <b>jam</b> to ignore <I>targets</I> that neither
554	can be found nor have updating actions to build them. Normally
555	for such targets <B>jam</B> issues a warning and then skips
556	other targets that depend on these missing targets. The HdrRule
557	in Jambase uses NOCARE on the header file names found during
558	header file scanning, to let <b>jam</b> know that the included
559	files may not exist. For example, if a #include is within an
560	#ifdef, the included file may not actually be around.
561
562	<P><DT><CODE>
563	NOTFILE <I>targets</I> ;
564	</CODE>
565
566	<DD> Marks <I>targets</I> as pseudotargets and not real files.
567	No timestamp is checked, and so the actions on such a target
568	are only executed if the target's dependencies are updated, or
569	if the target is also marked with ALWAYS. The default <b>jam</b>
570	target "all" is a pseudotarget. In Jambase, NOTFILE is used to
571	define several addition convenient pseudotargets.
572
573	<P><DT><CODE>
574	NOUPDATE <I>targets</I> ;
575	</CODE>
576
577	<DD> Causes the timestamps on <I>targets</I> to be ignored.
578	This has two effects: first, once the target has been created
579	it will never be updated; second, manually updating target will
580	not cause other targets to be updated. In Jambase, for example,
581	this rule is applied to directories by the MkDir rule, because
582	MkDir only cares that the target directory exists, not when it
583	has last been updated.
584
585	<P><DT><CODE>
586	TEMPORARY <I>targets</I> ;
587	</CODE>
588
589	<DD> Marks <I>targets</I> as temporary, allowing them to be
590	removed after other targets that depend upon them have been
591	updated. If a TEMPORARY target is missing, <b>jam</b> uses the
592	timestamp of the target's parent. Jambase uses TEMPORARY to
593	mark object files that are archived in a library after they are
594	built, so that they can be deleted after they are archived.
595
596	</DL></TABLE>
597
598	<P> <H5> Utility Rules </H5>
599
600	<P>
601
602	The two rules ECHO and EXIT are utility rules, used only in
603	<b>jam</b>'s parsing phase.
604
605	<P><TABLE WIDTH=75% ALIGN=CENTER><TR><TD><DL>
606
607	<P><DT><CODE>
608	ECHO <i>args</I> ;
609	</CODE>
610
611	<DD> Blurts out the message <i>args</I> to stdout.
612
613	<P><DT><CODE>
614	EXIT <i>args</I> ;
615	</CODE>
616
617	<DD> Blurts out the message <i>args</I> to stdout and then exits
618	with a failure status.
619
620	<P>
621
622	"Echo", "echo", "Exit", and "exit" are accepted as aliases for ECHO
623	and EXIT, since it is hard to tell that these are built-in
624	rules and not part of the language, like "include".
625
626	</DL></TABLE>
627
628	<P>
629
630	The GLOB rule does filename globbing.
631
632	<P><TABLE WIDTH=75% ALIGN=CENTER><TR><TD><DL>
633
634	<P><DT><CODE>
635	GLOB <i>directories</I> : <I>patterns</I> : <I>downcase-opt</I>
636	</CODE>
637
638	<DD> Using the same wildcards as for the patterns in the <A
639	HREF="#switch">switch</A> statement). It is invoked by being
640	used as an argument to a rule invocation inside of `[ ]`. For
641	example: "<TT>FILES = [ GLOB dir1 dir2 : .c .h ]</TT>" sets
642	A to the list of C source and header files in dir1 or dir2.
643	The resulting filenames are the full pathnames, including the
644	directory, but the pattern is applied only to the file name
645	without the directory.
646
647	<p>If <I>downcase-opt</I> is supplied, filenames are converted to
648	all-lowercase before matching against the pattern; you can use
649	this to do case-insensitive matching using lowercase patterns.
650	The paths returned will still have mixed case if the OS supplies
651	them. On Windows NT and Cygwin, filenames are always downcased
652	before matching.
653
654	</DL></TABLE>
655
656	<P>
657
658	The MATCH rule does pattern matching.
659
660	<P><TABLE WIDTH=75% ALIGN=CENTER><TR><TD><DL>
661
662	<P><DT><CODE>
663	MATCH <i>regexps</I> : <I>list</I>
664	</CODE>
665
666	<DD> Matches the <b>egrep</b>(1) style regular expressions
667	<I>regexps</I> against the strings in <I>list</I>. The result
668	is the concatenation of matching <tt>()</tt> subexpressions for
669	each string in <I>list</I>, and for each regular expression in
670	<I>regexps</I>. Only useful within the <tt>[ ]</tt> construct,
671	to change the result into a list.
672
673	</DL></TABLE>
674
675	<DT> <P> <H3> Flow-of-Control </H3> <DD>
676
677	<P>
678
679	Jam has several simple flow-of-control statements:
680
681	<P><TABLE WIDTH=75% ALIGN=CENTER><TR><TD><DL>
682
683	<P><DT><CODE>
684
685	for <I>var</I> in <I>list</I> { <I>statements</I> }
686
687	</CODE>
688
689	<P><DD> Executes <i>statements</i> for each element in
690	<i>list</i>, setting the variable <i>var</i> to the element
691	value.
692
693	<A name=if>
694	<P><DT><CODE>
695	</A>
696
697	if <I>cond</I> { <I>statements</I> }
698	<BR> [ else <I>statements</I> ]
699
700	</CODE>
701
702	<P><DD> Does the obvious; the else clause is optional.
703	<i>cond</i> is built of:
704
705	<TABLE>
706
707	<TR><TD> <CODE><I>a</I></CODE></TD>
708	<TD> true if any <I>a</I> element is a non-zero-length
709	string</TD>
710	<TR><TD> <CODE><I>a</I> = <I>b</I></CODE> </TD>
711	<TD> list <I>a</I> matches list <I>b</I>
712	string-for-string</TD>
713	<TR><TD> <CODE><I>a</I> != <I>b</I> </CODE></TD>
714	<TD> list <I>a</I> does not match list <I>b</I></TD>
715	<TR><TD> <CODE><I>a</I> < <I>b</I> </CODE></TD>
716	<TD> <I>a[i]</I> string is less than <I>b[i]</I>
717	string, where <i>i</i> is first mismatched element
718	in lists <I>a</I> and <I>b</I></TD>
719	<TR><TD> <CODE><I>a</I> <= <I>b</I> </CODE></TD>
720	<TD> every <I>a</I> string is less than or equal to
721	its <I>b</I> counterpart</TD>
722	<TR><TD> <CODE><I>a</I> > <I>b</I> </CODE></TD>
723	<TD> <I>a[i]</I> string is greater than <I>b[i]</I>
724	string, where <i>i</i> is first mismatched element</TD>
725	<TR><TD> <CODE><I>a</I> >= <I>b</I> </CODE></TD>
726	<TD> every <I>a</I> string is greater than or equal to
727	its <I>b</I> counterpart</TD>
728	<TR><TD> <CODE><I>a</I> in <I>b</I> </CODE></TD>
729	<TD> true if all elements of <I>a</I> can be found
730	in <I>b</I>, or if <I>a</I> has no elements</TD>
731	<TR><TD> <CODE>! <I>cond</I> </CODE></TD>
732	<TD> condition not true</TD>
733	<TR><TD> <CODE><I>cond</I> && <I>cond</I> </CODE></TD>
734	<TD> conjunction</TD>
735	<TR><TD> <CODE><I>cond</I> \|\| <I>cond</I> </CODE></TD>
736	<TD> disjunction</TD>
737	<TR><TD> <CODE>( <I>cond</I> ) </CODE></TD>
738	<TD> precedence grouping</TD>
739
740	</TABLE>
741
742	<P><DT> <CODE>
743
744	include <I>file</I> ;
745
746	</CODE>
747
748	<P><DD> Causes <b>jam</b> to read the named <i>file</i>.
749	The file is bound like a regular target (see <A
750	HREF="#binding"> Binding</A> above) but unlike a regular
751	target the include file cannot be built.
752
753	<P>
754
755	The include file is inserted into the input stream during
756	the parsing phase. The primary input file and all the included
757	file(s) are treated as a single file; that is, <b>jam</b>
758	infers no scope boundaries from included files.
759
760	<P><DT> <CODE>
761
762	local <i>vars</I> [ = <i>values</i> ] ;
763
764	</CODE>
765
766	<P><DD> Creates new <i>vars</i> inside to the enclosing {}
767	block, obscuring any previous values they might have. The
768	previous values for <i>vars</i> are restored when the current
769	block ends. Any rule called or file included will see the
770	local and not the previous value (this is sometimes called
771	Dynamic Scoping). The local statement may appear anywhere,
772	even outside of a block (in which case the previous value
773	is restored when the input ends). The <i>vars</i> are
774	initialized to <i>values</i> if present, or left uninitialized
775	otherwise.
776
777	<P><DT> <CODE>
778
779	return <I>values</I> ;
780
781	</CODE>
782
783	<P><DD> Within a rule body, the return statement sets the return
784	value for an invocation of the rule. It does <i>not</i> cause the
785	rule to return; a rule's value is actually the value of the
786	last statement executed, so a return should be the
787	last statement executed before the rule "naturally" returns.
788
789	<P><DT> <CODE>
790
791	<A NAME="switch">
792	switch <I>value</I>
793	</A>
794	<BR> {
795	<BR> case <I>pattern1</I> : <I>statements</I> ;
796	<BR> case <I>pattern2</I> : <I>statements</I> ;
797	<BR> ...
798	<BR> }
799
800	</CODE>
801
802	<P><DD> The switch statement executes zero or one of the
803	enclosed <i>statements</i>, depending on which, if any, is
804	the first case whose <i>pattern</I> matches <i>value</i>.
805	The <i>pattern</I> values are not variable-expanded. The
806	<i>pattern</I> values may include the following wildcards:
807
808	<TABLE>
809
810	<TR><TD><CODE> ? </CODE></TD>
811	<TD> match any single character </TD>
812	<TR><TD><CODE> * </CODE></TD>
813	<TD> match zero or more characters </TD>
814	<TR><TD><CODE> [<i>chars</i>] </CODE></TD>
815	<TD> match any single character in <i>chars</i> </TD>
816	<TR><TD><CODE> [^<i>chars</i>] </CODE></TD>
817	<TD> match any single character not in <i>chars</i> </TD>
818	<TR><TD><CODE> \<i>x</i> </CODE></TD>
819	<TD> match <i>x</i> (escapes the other wildcards)</i> </TD>
820
821	</TABLE>
822
823	<P><DT> <CODE>
824
825	while <I>cond</I> { <I>statements</I> }
826
827	</CODE>
828
829	<P><DD> Repeatedly execute <I>statements</I> while <I>cond</I>
830	remains true upon entry. (See the description of <I>cond</I>
831	expression syntax under <a href="#if">if</a>, above).
832	</DL></TABLE>
833
834	<DT> <P> <H3> Variables </H3> <DD>
835
836	<P>
837
838	<B>Jam</b> variables are lists of zero or more elements, with
839	each element being a string value. An undefined variable is
840	indistinguishable from a variable with an empty list, however,
841	a defined variable may have one more elements which are null
842	strings. All variables are referenced as $(<I>variable</I>).
843
844	<P>
845
846	Variables are either global or target-specific. In the latter
847	case, the variable takes on the given value only during the
848	updating of the specific target.
849
850	<P>
851
852	A variable is defined with:
853
854	<P> <TABLE WIDTH=75% ALIGN=CENTER> <TR><TD> <DL>
855
856	<DT><CODE>
857	<I>variable</I> = <I>elements</I> ; </CODE>
858	<DT><CODE>
859	<I>variable</I> += <I>elements</I> ; </CODE>
860	<DT><CODE>
861	<I>variable</I> on <I>targets</I> = <I>elements</I> ; </CODE>
862	<DT><CODE>
863	<I>variable</I> on <I>targets</I> += <I>elements</I> ; </CODE>
864	<DT><CODE>
865	<I>variable</I> default = <I>elements</I> ; </CODE>
866	<DT><CODE>
867	<I>variable</I> ?= <I>elements</I> ; </CODE>
868
869	</DL></TABLE>
870
871	<P>
872
873	The first two forms set <I>variable</I> globally. The third
874	and forth forms set a target-specific variable. The = operator
875	replaces any previous elements of <I>variable</I> with
876	<I>elements</I>; the += operation adds <I>elements</I> to
877	<I>variable</I>'s list of elements. The final two forms are
878	synonymous: they set <I>variable</I> globally, but only if it
879	was previously unset.
880
881	<P>
882
883	Variables referenced in updating commands will be replaced with
884	their values; target-specific values take precedence over global
885	values. Variables passed as arguments ($(1) and $(2)) to actions
886	are replaced with their bound values; the "bind" modifier can
887	be used on actions to cause other variables to be replaced with
888	bound values. See <A HREF="#actionmods">Action Modifiers</A>
889	above.
890
891	<P>
892
893	<B>Jam</b> variables are not re-exported to the environment of
894	the shell that executes the updating actions, but the updating
895	actions can reference <b>jam</b> variables with $(<I>variable</I>).
896
897	<P> <H4> Variable Expansion </H4>
898
899	<P>
900
901	During parsing, <b>jam</b> performs variable expansion on each
902	token that is not a keyword or rule name. Such tokens with
903	embedded variable references are replaced with zero or more
904	tokens. Variable references are of the form $(<I>v</I>) or
905	$(<I>vm</I>), where <i>v</i> is the variable name, and <I>m</I>
906	are optional modifiers.
907
908	<P>
909
910	Variable expansion in a rule's actions is similar to variable
911	expansion in statements, except that the action string is
912	tokenized at whitespace regardless of quoting.
913
914	<P>
915
916	The result of a token after variable expansion is the
917	<i>product</i> of the components of the token, where each
918	component is a literal substring or a list substituting a variable
919	reference. For example:
920
921	<P> <TABLE WIDTH=75% ALIGN=CENTER><TR><TD><CODE>
922
923	<BR>$(X) -> a b c
924	<BR>t$(X) -> ta tb tc
925	<BR>$(X)z -> az bz cz
926	<BR>$(X)-$(X) -> a-a a-b a-c b-a b-b b-c c-a c-b c-c
927
928	</CODE></TABLE>
929
930	<P>
931
932	The variable name and modifiers can themselves contain
933	a variable reference, and this partakes of the product
934	as well:
935
936	<P> <TABLE WIDTH=75% ALIGN=CENTER><TR><TD><CODE>
937
938	<BR>$(X) -> a b c
939	<BR>$(Y) -> 1 2
940	<BR>$(Z) -> X Y
941	<BR>$($(Z)) -> a b c 1 2
942
943	</CODE></TABLE>
944
945	<P>
946
947	Because of this product expansion, if any variable reference in
948	a token is undefined, the result of the expansion is an empty
949	list. If any variable element is a null string, the result
950	propagates the non-null elements:
951
952	<P> <TABLE WIDTH=75% ALIGN=CENTER><TR><TD><CODE>
953
954	<BR>$(X) -> a ""
955	<BR>$(Y) -> "" 1
956	<BR>$(Z) ->
957	<BR>$(X)$(Y) -> a a1 ** 1
958	<BR>$(X)$(Z) ->
959
960	</CODE></TABLE>
961
962	<P>
963
964	A variable element's string value can be parsed into grist and
965	filename-related components. Modifiers to a variable are used
966	to select elements, select components, and replace components.
967	The modifiers are:
968
969	<P> <TABLE WIDTH=75% ALIGN=CENTER>
970
971	<TR><TD><CODE> [<I>n</I>] </CODE>
972	<TD>Select element number <I>n</I> (starting at 1). If
973	the variable contains fewer than <I>n</I> elements,
974	the result is a zero-element list.
975
976	<TR><TD><CODE> [<I>n</I>-<I>m</I>] </CODE>
977	<TD>Select elements number <I>n</I> through <I>m</I>.
978
979	<TR><TD><CODE> [<I>n</I>-] </CODE>
980	<TD>Select elements number <I>n</I> through the last.
981
982	<TR><TD><CODE> :B </CODE>
983	<TD>Select filename base.
984
985	<TR><TD><CODE> :S </CODE>
986	<TD>Select (last) filename suffix.
987
988	<TR><TD><CODE> :M </CODE>
989	<TD>Select archive member name.
990
991	<TR><TD><CODE> :D </CODE>
992	<TD>Select directory path.
993
994	<TR><TD><CODE> :P </CODE>
995	<TD>Select parent directory.
996
997	<TR><TD><CODE> :G </CODE>
998	<TD>Select grist.
999
1000	<TR><TD><CODE> :U </CODE>
1001	<TD>Replace lowercase characters with uppercase.
1002
1003	<TR><TD><CODE> :L </CODE>
1004	<TD>Replace uppercase characters with lowercase.
1005
1006	<TR><TD><CODE> :<i>chars</I> </CODE>
1007	<TD>Select the components listed in <i>chars</i>.
1008
1009	<TR><TD><CODE> :G=<I>grist</I> </CODE>
1010	<TD>Replace grist with <I>grist</I>.
1011
1012	<TR><TD><CODE> :D=<I>path</I> </CODE>
1013	<TD>Replace directory with <I>path</I>.
1014
1015	<TR><TD><CODE> :B=<I>base</I> </CODE>
1016	<TD>Replace the base part of file name with <I>base</I>.
1017
1018	<TR><TD><CODE> :S=<I>suf</I> </CODE>
1019	<TD>Replace the suffix of file name with <I>suf</I>.
1020
1021	<TR><TD><CODE> :M=<I>mem</I> </CODE>
1022	<TD>Replace the archive member name with <I>mem</I>.
1023
1024	<TR><TD><CODE> :R=<I>root</I> </CODE>
1025	<TD>Prepend <I>root</I> to the whole file name, if not
1026	already rooted.
1027
1028	<TR><TD><CODE> :E=<I>value</I> </CODE>
1029	<TD>Assign <I>value</I> to the variable if it is unset.
1030
1031	<TR><TD><CODE> :J=<I>joinval</I> </CODE>
1032	<TD>Concatentate list elements into single
1033	element, separated by <I>joinval</I>.
1034
1035	</TABLE>
1036
1037	<P>
1038
1039	On VMS, $(var:P) is the parent directory of $(var:D).
1040
1041	<DT> <P> <H3> Built-in Variables </H3> <DD>
1042
1043	<P>
1044
1045	This section discusses variables that have special meaning to
1046	<b>jam</b>.
1047
1048	<A NAME="search">
1049	<P> <H4> SEARCH and LOCATE Variables </H4>
1050	</A>
1051
1052	<P>
1053
1054	These two variables control the binding of file target names to
1055	locations in the file system. Generally, $(SEARCH) is used to
1056	find existing sources while $(LOCATE) is used to fix the location
1057	for built targets.
1058
1059	<P>
1060
1061	Rooted (absolute path) file targets are bound as is. Unrooted
1062	file target names are also normally bound as is, and thus relative
1063	to the current directory, but the settings of $(LOCATE) and
1064	$(SEARCH) alter this:
1065
1066	<P>
1067
1068	<UL>
1069
1070	<LI> If $(LOCATE) is set then the target is bound relative to
1071	the first directory in $(LOCATE). Only the first element is
1072	used for binding.
1073
1074	<LI> If $(SEARCH) is set then the target is bound to the first
1075	directory in $(SEARCH) where the target file already exists.
1076
1077	<LI> If the $(SEARCH) search fails, the target is bound relative
1078	to the current directory anyhow.
1079
1080	</UL>
1081
1082	<P>
1083
1084	Both $(SEARCH) and $(LOCATE) should be set target-specific and
1085	not globally. If they were set globally, <b>jam</b> would use
1086	the same paths for all file binding, which is not likely to
1087	produce sane results. When writing your own rules, especially
1088	ones not built upon those in Jambase, you may need to set
1089	$(SEARCH) or $(LOCATE) directly. Almost all of the rules defined
1090	in Jambase set $(SEARCH) and $(LOCATE) to sensible values for
1091	sources they are looking for and targets they create, respectively.
1092
1093	<A NAME="hdrscan">
1094	<P> <H4> HDRSCAN and HDRRULE Variables </H4>
1095	</A>
1096
1097	<P>
1098
1099	These two variable control header file scanning. $(HDRSCAN) is
1100	an <b>egrep</b>(1) pattern, with ()'s surrounding the file name,
1101	used to find file inclusion statements in source files. Jambase
1102	uses $(HDRPATTERN) as the pattern for $(HDRSCAN). $(HDRRULE)
1103	is the name of a rule to invoke with the results of the scan:
1104	the scanned file is the target, the found files are the sources.
1105	This is the only place where <b>jam</b> invokes a rule through
1106	a variable setting.
1107
1108	<P>
1109
1110	Both $(HDRSCAN) and $(HDRRULE) must be set for header file
1111	scanning to take place, and they should be set target-specific
1112	and not globally. If they were set globally, all files, including
1113	executables and libraries, would be scanned for header file
1114	include statements.
1115
1116	<P>
1117
1118	The scanning for header file inclusions is not exact, but it is
1119	at least dynamic, so there is no need to run something like
1120	<b>makedepend</b>(GNU) to create a static dependency file. The
1121	scanning mechanism errs on the side of inclusion (i.e., it is
1122	more likely to return filenames that are not actually used by
1123	the compiler than to miss include files) because it can't tell
1124	if #include lines are inside #ifdefs or other conditional logic.
1125	In Jambase, HdrRule applies the NOCARE rule to each header file
1126	found during scanning so that if the file isn't present yet
1127	doesn't cause the compilation to fail, <b>jam</b> won't care.
1128
1129	<P>
1130
1131	Also, scanning for regular expressions only works where the
1132	included file name is literally in the source file. It can't
1133	handle languages that allow including files using variable names
1134	(as the Jam language itself does).
1135
1136	<P> <H4> Platform Identifier Variables </H4>
1137
1138	<P>
1139
1140	A number of Jam built-in variables can be used to identify
1141	runtime platform:
1142
1143	<P>
1144
1145	<TABLE WIDTH=75% ALIGN=CENTER>
1146
1147	<TR><TD>OS<TD>OS identifier string
1148	<TR><TD>OSPLAT<TD>Underlying architecture, when applicable
1149	<TR><TD>MAC<TD>true on MAC platform
1150	<TR><TD>NT<TD>true on NT platform
1151	<TR><TD>OS2<TD>true on OS2 platform
1152	<TR><TD>UNIX<TD>true on Unix platforms
1153	<TR><TD>VMS<TD>true on VMS platform
1154
1155	</TABLE>
1156
1157	<P> <H4> Jam Version Variables </H4>
1158
1159	<P>
1160
1161	<TABLE WIDTH=75% ALIGN=CENTER>
1162
1163	<TR><TD>JAMDATE<TD>Time and date at <b>jam</b> start-up.
1164	<TR><TD>JAMUNAME<TD>Ouput of <b>uname</b>(1) command (Unix only)
1165	<TR><TD>JAMVERSION<TD><b>jam</b> version, currently "2.3"
1166
1167	</TABLE>
1168
1169	<P> <H4> JAMSHELL Variable </H4>
1170
1171	<P>
1172
1173	When <b>jam</b> executes a rule's action block, it forks and
1174	execs a shell, passing the action block as an argument to the
1175	shell. The invocation of the shell can be controlled by
1176	$(JAMSHELL). The default on Unix is, for example:
1177
1178	<P>
1179
1180	<CODE>JAMSHELL = /bin/sh -c % ;</CODE>
1181
1182	<P>
1183
1184	The % is replaced with the text of the action block.
1185
1186	<P>
1187
1188	<B>Jam</b> does not directly support building in parallel across
1189	multiple hosts, since that is heavily dependent on the local
1190	environment. To build in parallel across multiple hosts, you
1191	need to write your own shell that provides access to the multiple
1192	hosts. You then reset $(JAMSHELL) to reference it.
1193
1194	<P>
1195
1196	Just as <b>jam</b> expands a % to be the text of the rule's
1197	action block, it expands a ! to be the multi-process slot number.
1198	The slot number varies between 1 and the number of concurrent
1199	jobs permitted by the -j flag given on the command line. Armed
1200	with this, it is possible to write a multiple host shell. For
1201	example:
1202
1203	<P>
1204
1205	<TABLE WIDTH=75% ALIGN=CENTER><TR><TD><CODE>
1206
1207	<BR>#!/bin/sh
1208	<BR>
1209	<BR># This sample JAMSHELL uses the SunOS on(1) command to execute a
1210	<BR># command string with an identical environment on another host.
1211	<BR>
1212	<BR># Set JAMSHELL = jamshell ! %
1213	<BR>#
1214	<BR># where jamshell is the name of this shell file.
1215	<BR>#
1216	<BR># This version handles up to -j6; after that they get executed
1217	<BR># locally.
1218	<BR>
1219	<BR>case $1 in
1220	<BR>1\|4) on winken sh -c "$2";;
1221	<BR>2\|5) on blinken sh -c "$2";;
1222	<BR>3\|6) on nod sh -c "$2";;
1223	<BR>*) eval "$2";;
1224	<BR>esac
1225
1226	</CODE></TABLE>
1227
1228
1229	<DT> <P> <H2> DIAGNOSTICS </H2> <DD>
1230
1231	<P>
1232
1233	In addition to generic error messages, <B>jam</B> may emit one of
1234	the following:
1235
1236	<P><TABLE WIDTH=75% ALIGN=CENTER><TR><TD><DL>
1237
1238	<P><DT><CODE> warning: unknown rule X </CODE> <DD>
1239
1240	A rule was invoked that has not been defined with
1241	an "actions" or "rule" statement.
1242
1243	<P><DT><CODE> using N temp target(s) </CODE> <DD>
1244
1245	Targets marked as being temporary (but nonetheless
1246	present) have been found.
1247
1248	<P><DT><CODE> updating N target(s) </CODE> <DD>
1249
1250	Targets are out-of-date and will be updated.
1251
1252	<P><DT><CODE> can't find N target(s) </CODE> <DD>
1253
1254	Source files can't be found and there are no
1255	actions to create them.
1256
1257	<P><DT><CODE> can't make N target(s) </CODE> <DD>
1258
1259	Due to sources not being found, other targets cannot be made.
1260
1261	<P><DT><CODE> warning: X depends on itself </CODE> <DD>
1262
1263	A target depends on itself either directly or
1264	through its sources.
1265
1266	<P><DT><CODE> don't know how to make X </CODE> <DD>
1267
1268	A target is not present and no actions have been
1269	defined to create it.
1270
1271	<P><DT><CODE> X skipped for lack of Y </CODE> <DD>
1272
1273	A source failed to build, and thus a target cannot
1274	be built.
1275
1276	<P><DT><CODE> warning: using independent target X </CODE> <DD>
1277
1278	A target that is not a dependency of any other
1279	target is being referenced with $(<) or $(>).
1280
1281	<P><DT><CODE> X removed </CODE> <DD>
1282
1283	<b>Jam</b> removed a partially built target after being
1284	interrupted.
1285
1286	</DL></TABLE>
1287
1288	<DT> <P> <H2> BUGS, LIMITATIONS </H2> <DD>
1289
1290	<P>
1291
1292	The -j flag can cause <B>jam</B> to get confused when single
1293	actions update more than one target at a time. <B>jam</B> may
1294	proceed as if the targets were built even though they are still
1295	under construction.
1296
1297	<P>
1298
1299	For parallel building to be successful, the dependencies among
1300	files must be properly spelled out, as targets tend to get built
1301	in a quickest-first ordering. Also, beware of un-parallelizable
1302	commands that drop fixed-named files into the current directory,
1303	like <b>yacc</b>(1) does.
1304
1305	<P>
1306
1307	With the -j flag, errors from failed commands can get staggeringly
1308	mixed up.
1309
1310	<P>
1311
1312	A poorly set $(JAMSHELL) is likely to result in silent failure.
1313
1314	<DT> <P> <H2> SEE ALSO </H2> <DD>
1315
1316	<P>
1317
1318	<UL>
1319
1320	<LI> <a href="Jambase.html">Jambase Reference</a>
1321
1322	<LI> <a href="Jamfile.html">Using Jamfiles and Jambase</a>
1323
1324	</UL>
1325
1326	<P>
1327
1328	Jam documentation and source are available from the <A
1329	HREF="http://public.perforce.com/public/index.html">Perforce
1330	Public Depot</a>.
1331
1332	<DT> <P> <H2> AUTHOR </H2> <DD>
1333
1334	<P>
1335	Jam's author is Christopher Seiwald (<a
1336	href="mailto:seiwald@perforce.com">seiwald@perforce.com</A>).
1337	Documentation is provided by
1338	<A HREF="http://www.perforce.com">Perforce Software, Inc.</A>
1339
1340	</DL>
1341
1342	<P> <HR>
1343
1344	<P>
1345
1346	Copyright 1993-2002 Christopher Seiwald and Perforce Software, Inc.
1347	<BR>
1348	Comments to <A HREF="mailto:info@perforce.com">info@perforce.com</A>
1349	<BR>
1350	Last updated: April 1, 2002
1351	<BR>
1352	$Id: Jam.html,v 1.6 2003/09/01 08:04:33 vladimir_prus Exp $
1353
1354	</BODY>
1355	</HTML>
1356

Note: See TracBrowser for help on using the repository browser.

Download in other formats: