summaryrefslogtreecommitdiff
path: root/config
blob: c7a62a32b139077a27ab1907bce83e2cb25c3f63 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
/*
 *	aegis - project change supervisor
 *	This file is in the Public Domain, 1995, Peter Miller.
 *
 * MANIFEST: example use of make in project config file
 *
 * The make(1) program exists in many forms, usually one is available with each
 * UNIX version.  The one used in the writing of this section is GNU Make 3.70,
 * avaiable by anonymous FTP from your nearest GNU archive site.  GNU Make was
 * chosen because it was the most powerful, it is widely avaiable (usually for
 * little or no cost) and discussion of the alternatives (SunOS make, BSD 4.3
 * make, etc), would not be universally applicable.  "Plain vanilla" make
 * (with no transitive closure, no pattern rules, no functions) is not
 * sufficiently capable to satisfy the demands placed on it by aegis.
 *
 * As mentioned in the Dependency Maintenance Tool chapter of the User Guide,
 * make is not really sufficient, because it lacks dynamic include dependencies.
 * However, GNU Make has a form of dynamic include dependencies, and it has a
 * few quirks, but mostly works well.
 *
 * The other feature lacking in make is a search path.  While GNU Make has
 * functionality called VPATH, the implementation leaves something to be
 * desired, and can't be used for the search path functionality required by
 * aegis.  Because of this, the create_symlinks_before_build field of the
 * project config file is set to true so that aegis will arrange for the
 * development directory to be fiull of symbolic links, making it appear that
 * the entire project is in each change's development directory.
 */

/*
 * The build_command field of the project config file is used to invoke the
 * relevant build command.  This command tells make where to find the rules.
 * The ${s Makefile} expands to a path into the baseline during development
 * if the file is not in the change.  Look in aesub(5) for more information
 * about command substitutions.
 */
build_command = "SCONS_LIB_DIR=src/engine python ${Source src/script/scons.py} date='${DAte %Y/%m/%d %H:%M:%S}' developer=${DEVeloper} version=${VERsion} change=${Change}";

/*
 * The rules used in the User Guide all remove their targets before
 * constructing them, which qualifies them for the following entry in the
 * config file.  The files must be removed first, otherwise the baseline would
 * cease to be self-consistent.
 */
link_integration_directory = true;

/*
 * Another field to be set in this file is one which tells aegis to maintain
 * symbolic links between the development directory and the basline.  This also
 * requires that rules remove their targets before constructing them, to ensure
 * that development builds do not attempt to write their results onto the
 * read-only versions in the baseline.
 */
create_symlinks_before_build = true;

remove_symlinks_after_build = false;

/*
integrate_begin_command =
	"";
*/

/*
 *	aegis - project change supervisor
 *	This file is in the Public Domain, 1995, 1998 Peter Miller.
 *
 * MANIFEST: example of using rcs in the project config file
 *
 * The entries for the commands are listed below.  RCS uses a slightly
 * different model than aegis wants, so some maneuvering is required.
 * The command strings in this section assume that the RCS commands ci and co
 * and rcs and rlog are in the command search PATH, but you may like to
 * hard-wire the paths, or set PATH at the start of each.  You should also note
 * that the strings are always handed to the Bourne shell to be executed, and
 * are set to exit with an error immediately a sub-command fails.
 *
 * In these commands, the RCS file is kept unlocked, since only the owner will
 * be checking changes in.  The RCS functionality for coordinating shared
 * access is not required.
 *
 * One advantage of using RCS version 5.6 or later is that binary files are
 * supported, should you want to have binary files in the baseline.
 *
 * The ${quote ...} construct is used to quote filenames which contain
 * shell special characters.  A minimum of quoting is performed, so if
 * the filenames do not contail shell special characters, no quotes will
 * be used.
 */

/*
 * This command is used to create a new file history.
 * This command is always executed as the project owner.
 * The following substitutions are available:
 *
 * ${Input}
 *	absolute path of the source file
 * ${History}
 *	absolute path of the history file
 *
 * The "ci -f" option is used to specify that a copy is to be checked-in even
 *	if there are no changes.
 * The "ci -u" option is used to specify that an unlocked copy will remain in
 *	the baseline.
 * The "ci -d" option is used to specify that the file time rather than the
 *	current time is to be used for the new revision.
 * The "ci -M" option is used to specify that the mode date on the original
 *	file is not to be altered.
 * The "ci -t" option is used to specify that there is to be no description
 *	text for the new RCS file.
 * The "ci -m" option is used to specify that the change number is to be stored
 *	in the file log if this is actually an update (typically from aenf
 *	after aerm on the same file name).
 * The "rcs -U" option is used to specify that the new RCS file is to have
 *	unstrict locking.
 * The "rcs -kk" option is used to specify that keyword substitution is
 *	disabled (only keyword names, not values, are substituted).
 */
history_create_command =
	"ci -f -u -d -M -m$c -t/dev/null ${quote $input} ${quote $history,v}; \
rcs -kk -U ${quote $history,v}";


/*
 * This command is used to get a specific edit back from history.
 * This command is always executed as the project owner.
 * The following substitutions are available:
 *
 * ${History}
 *	absolute path of the history file
 * ${Edit}
 *	edit number, as given by history_\%query_\%command
 * ${Output}
 *	absolute path of the destination file
 *
 * The "co -r" option is used to specify the edit to be retrieved.
 * The "co -p" option is used to specify that the results be printed on the
 *	standard output; this is because the destination filename will never
 *	look anything like the history source filename.
 * The "rcs -kk" option is used to specify that keyword substitution is
 *	disabled (only keyword names, not values, are substituted).
 */
history_get_command =
	"co -kk -r${quote $edit} -p ${quote $history,v} > ${quote $output}";

/*
 * This command is used to add a new "top-most" entry to the history file.
 * This command is always executed as the project owner.
 * The following substitutions are available:
 *
 * ${Input}
 *	absolute path of source file
 * ${History}
 *	absolute path of history file
 *
 * The "ci -f" option is used to specify that a copy is to be checked-in even
 *	if there are no changes.
 * The "ci -u" option is used to specify that an unlocked copy will remain in
 *	the baseline.
 * The "ci -d" option is used to specify that the file time rather than the
 *	current time is to be used for the new revision.
 * The "ci -M" option is used to specify that the mode date on the original
 *	file is not to be altered.
 * The "ci -m" option is used to specify that the change number is to be stored
 *	in the file log, which allows rlog to be used to find the change
 *	numbers to which each revision of the file corresponds.
 *
 * It is possible for a a very cautious approach has been taken, in which case
 * the history_put_command may be set to the same string specified above for
 * the history_create_command.
 */
history_put_command =
	"ci -f -u -d -M -m$c ${quote $input} ${quote $history,v}";

/*
 * This command is used to query what the history mechanism calls the top-most
 * edit of a history file.  The result may be any arbitrary string, it need not
 * be anything like a number, just so long as it uniquely identifies the edit
 * for use by the history_get_command at a later date.  The edit number is to
 * be printed on the standard output.  This command is always executed as the
 * project owner.
 *
 * The following substitutions are available:
 *
 * ${History}
 *	absolute path of the history file
 */
history_query_command =
	"rlog -r ${quote $history,v} | awk '/^head:/ {print $$2}'";

/*
 * RCS also provides a merge program, which can be used to provide a three-way
 * merge.  It has an ouput format some sites prefer to the fmerge output.
 *
 * This command is used by aed(1) to produce a difference listing when a file
 * in the development directory is out of date compared to the current version
 * in the baseline.
 *
 * All of the command substitutions described in aesub(5) are available.
 * In addition, the following substitutions are also available:
 *
 * ${ORiginal}
 *	The absolute path name of a file containing the common ancestor
 *	version of ${MostRecent} and {$Input}.  Usually the version originally
 *	copied into the change.  Usually in a temporary file.
 * ${Most_Recent}
 *	The absolute path name of a file containing the most recent version.
 *	Usually in the baseline.
 * ${Input}
 *	The absolute path name of the edited version of the file.  Usually in
 *	the development directory.
 * ${Output}
 *	The absolute path name of the file in which to write the difference
 *	listing.  Usually in the development directory.
 *
 * An exit status of 0 means successful, even of the files differ (and they
 * usually do).  An exit status which is non-zero means something is wrong.
 *
 * The "merge -L" options are used to specify labels for the baseline and the
 *	development directory, respecticvely, when conflict lines are inserted
 *	into the result.
 * The "merge -p" options is used to specify that the results are to be printed
 *	on the standard output.
 */

diff3_command =
	"set +e; \
merge -p -L baseline -L C$c ${quote $mostrecent} ${quote $original} \
${quote $input} > ${quote $output}; \
test $? -le 1";

diff_command =
	"set +e; \
	diff -c ${quote $original} ${quote $input} > ${quote $output}; \
	test $? -le 1";

/*
 * We use an intermediary test.pl script to execute tests.
 * This serves as glue between the tests themselves (which are
 * written to conform to Perl conventions) and Aegis' expectations.
 * See the comments in the test.pl script itself for details.
 */
test_command = "python ${Source runtest.py Absolute} -p tar-gz -q ${File_Name}";

new_test_filename = "test/CHANGETHIS.py";

/*
 *
 */
file_template =
[
	{
		pattern = [ "src/engine/*__init__.py" ];
		body = "${read_file ${source template/__init__.py abs}}";
	},
	{
		pattern = [ "src/engine/*Tests.py" ];
		body = "${read_file ${source template/Tests.py abs}}";
	},
	{
		pattern = [ "src/engine/*.py" ];
		body = "${read_file ${source template/file.py abs}}";
	},
	{
		pattern = [ "test/*.py" ];
		body = "${read_file ${source template/test.py abs}}";
	},
];