2 * MANIFEST: use of SCons in project config file to build itself
4 * SCons has a Repository feature, introduced in SCons 0.09, that was
5 * designed to work well with Aegis.
9 * The build_command field of the project config file is used to invoke
10 * the relevant build command. This command tells SCons where to find
13 * Our chicken-and-egg dilemma is this: we want to use the version of
14 * SCons under development in an Aegis change to build itself. But the
15 * pieces of SCons are likely only partly in this change, and partly in
18 * Python only imports things on a module-by-module basis--which is to
19 * say, once it finds __init__.py in a given directory, it assumes that
20 * all other files in that module are in the same directory. But that's
21 * not the way Aegis works, because if a file hasn't changed on the
22 * branch, it will only be in its parent's baseline directory.
24 * Aegis' mechanism for working around this sort of problem is to make
25 * symlinks to the proper baseline versions of each file, which makes
26 * it look like everything is in the local tree. That's unattractive,
27 * though, because we really want to eat our own dog food and use the
28 * SCons -Y options to pull things from the baseline repositories.
30 * So our solution (suggested by Anthony Roach) is a bootstrap.py script
31 * that does some Aegis-like searching through the baseline directories
32 * and makes a bootstrap copy of the version of SCons under development
33 * that we can use for building. After it makes this copy of SCons, it
34 * executes it with the same command-line arguments we supplied (and
35 * setting $SCONS_LIB_DIR to the right directory) so we can use it
36 * here with command-line options as if it were SCons itself. (Note,
37 * however, that bootstrap.py only understands the specific command-line
38 * options already in use here, so if you change the call below to add
39 * some other SCons options, you may have to modify bootstrap.py to
42 * The ${Source bootstrap.py} substitution finds bootstrap.py wherever
43 * it may be in the Aegis baselines.
45 * The long -Y${SUBSTitute...} substitution takes the Aegis baseline
46 * search path and turns it into the right -Y command-line options for
49 * The rest of the substitutions (${DEVeloper}, etc.) should be obvious.
51 * Look in aesub(5) for more information about command substitutions.
53 build_command = "python2.1 ${Source bootstrap.py} -Y${SUBSTitute : \\ -Y $Search_Path} date='${DAte %Y/%m/%d %H:%M:%S}' developer=${DEVeloper} version=${VERsion} change=${Change}";
56 * SCons removes its targets before constructing them, which qualifies it
57 * for the following entry in the config file. The files must be removed
58 * first, otherwise the baseline would cease to be self-consistent.
61 link_integration_directory = true;
64 * This is set temporarily to allow us to build using the SCons
65 * currently checked in to the src directory.
66 create_symlinks_before_build = true;
70 * aegis - project change supervisor
71 * This file is in the Public Domain, 1995, 1998 Peter Miller.
73 * MANIFEST: example of using rcs in the project config file
75 * The entries for the commands are listed below. RCS uses a slightly
76 * different model than aegis wants, so some maneuvering is required.
77 * The command strings in this section assume that the RCS commands ci and co
78 * and rcs and rlog are in the command search PATH, but you may like to
79 * hard-wire the paths, or set PATH at the start of each. You should also note
80 * that the strings are always handed to the Bourne shell to be executed, and
81 * are set to exit with an error immediately a sub-command fails.
83 * In these commands, the RCS file is kept unlocked, since only the owner will
84 * be checking changes in. The RCS functionality for coordinating shared
85 * access is not required.
87 * One advantage of using RCS version 5.6 or later is that binary files are
88 * supported, should you want to have binary files in the baseline.
90 * The ${quote ...} construct is used to quote filenames which contain
91 * shell special characters. A minimum of quoting is performed, so if
92 * the filenames do not contail shell special characters, no quotes will
97 * This command is used to create a new file history.
98 * This command is always executed as the project owner.
99 * The following substitutions are available:
102 * absolute path of the source file
104 * absolute path of the history file
106 * The "ci -f" option is used to specify that a copy is to be checked-in even
107 * if there are no changes.
108 * The "ci -u" option is used to specify that an unlocked copy will remain in
110 * The "ci -d" option is used to specify that the file time rather than the
111 * current time is to be used for the new revision.
112 * The "ci -M" option is used to specify that the mode date on the original
113 * file is not to be altered.
114 * The "ci -t" option is used to specify that there is to be no description
115 * text for the new RCS file.
116 * The "ci -m" option is used to specify that the change number is to be stored
117 * in the file log if this is actually an update (typically from aenf
118 * after aerm on the same file name).
119 * The "rcs -U" option is used to specify that the new RCS file is to have
121 * The "rcs -kk" option is used to specify that keyword substitution is
122 * disabled (only keyword names, not values, are substituted).
124 history_create_command =
125 "ci -f -u -d -M -m$c -t/dev/null ${quote $input} ${quote $history,v}; \
126 rcs -kk -U ${quote $history,v}";
130 * This command is used to get a specific edit back from history.
131 * This command is always executed as the project owner.
132 * The following substitutions are available:
135 * absolute path of the history file
137 * edit number, as given by history_\%query_\%command
139 * absolute path of the destination file
141 * The "co -r" option is used to specify the edit to be retrieved.
142 * The "co -p" option is used to specify that the results be printed on the
143 * standard output; this is because the destination filename will never
144 * look anything like the history source filename.
145 * The "rcs -kk" option is used to specify that keyword substitution is
146 * disabled (only keyword names, not values, are substituted).
148 history_get_command =
149 "co -kk -r${quote $edit} -p ${quote $history,v} > ${quote $output}";
152 * This command is used to add a new "top-most" entry to the history file.
153 * This command is always executed as the project owner.
154 * The following substitutions are available:
157 * absolute path of source file
159 * absolute path of history file
161 * The "ci -f" option is used to specify that a copy is to be checked-in even
162 * if there are no changes.
163 * The "ci -u" option is used to specify that an unlocked copy will remain in
165 * The "ci -d" option is used to specify that the file time rather than the
166 * current time is to be used for the new revision.
167 * The "ci -M" option is used to specify that the mode date on the original
168 * file is not to be altered.
169 * The "ci -m" option is used to specify that the change number is to be stored
170 * in the file log, which allows rlog to be used to find the change
171 * numbers to which each revision of the file corresponds.
173 * It is possible for a a very cautious approach has been taken, in which case
174 * the history_put_command may be set to the same string specified above for
175 * the history_create_command.
177 history_put_command =
178 "ci -f -u -d -M -m$c ${quote $input} ${quote $history,v}";
181 * This command is used to query what the history mechanism calls the top-most
182 * edit of a history file. The result may be any arbitrary string, it need not
183 * be anything like a number, just so long as it uniquely identifies the edit
184 * for use by the history_get_command at a later date. The edit number is to
185 * be printed on the standard output. This command is always executed as the
188 * The following substitutions are available:
191 * absolute path of the history file
193 history_query_command =
194 "rlog -r ${quote $history,v} | awk '/^head:/ {print $$2}'";
197 * RCS also provides a merge program, which can be used to provide a three-way
198 * merge. It has an ouput format some sites prefer to the fmerge output.
200 * This command is used by aed(1) to produce a difference listing when a file
201 * in the development directory is out of date compared to the current version
204 * All of the command substitutions described in aesub(5) are available.
205 * In addition, the following substitutions are also available:
208 * The absolute path name of a file containing the common ancestor
209 * version of ${MostRecent} and {$Input}. Usually the version originally
210 * copied into the change. Usually in a temporary file.
212 * The absolute path name of a file containing the most recent version.
213 * Usually in the baseline.
215 * The absolute path name of the edited version of the file. Usually in
216 * the development directory.
218 * The absolute path name of the file in which to write the difference
219 * listing. Usually in the development directory.
221 * An exit status of 0 means successful, even of the files differ (and they
222 * usually do). An exit status which is non-zero means something is wrong.
224 * The "merge -L" options are used to specify labels for the baseline and the
225 * development directory, respecticvely, when conflict lines are inserted
227 * The "merge -p" options is used to specify that the results are to be printed
228 * on the standard output.
233 merge -p -L baseline -L C$c ${quote $mostrecent} ${quote $original} \
234 ${quote $input} > ${quote $output}; \
238 * The diff command in Red Hat 8.0 changed the exit status so it *fails*
239 * when *it* thinks it's trying to diff a binary (non-ASCII-text) file.
240 * The -a option disables this behavior and makes diff's exit status
241 * behave like it used to, even on any binary files we have checked in.
246 diff -a -c ${quote $original} ${quote $input} > ${quote $output}; \
250 * We use a runtest.py script to execute tests. This takes care of
251 * massaging environment variables and the like to test against the
252 * unpacked package in the current directory.
254 * Note that we must include $spe in the batch_test_command line (so
255 * that Aegis thinks we're smart about testing ourselves against the
256 * baseline) but we don't actually need it. Our tests always run
257 * relative to the package built under the current directory, which
258 * is set appropriately during a baseline test. So we just use the
259 * proper aesub variable to comment out the expanded $spe.
261 test_command = "python1.5 ${Source runtest.py Absolute} --noqmtest -p tar-gz -t -v ${SUBSTitute '\\.[CD][0-9]+$' '' ${VERsion}} -q --sp ${Search_Path} --spe ${Search_Path_Executable} ${File_Name}";
263 batch_test_command = "python1.5 ${Source runtest.py Absolute} --noqmtest -p tar-gz -t -v ${SUBSTitute '\\.[CD][0-9]+$' '' ${VERsion}} -o ${Output} --aegis --sp ${Search_Path} --spe ${Search_Path_Executable} ${File_Names}";
265 new_test_filename = "test/CHANGETHIS.py";
273 pattern = [ "src/engine/*__init__.py" ];
274 body = "${read_file ${source template/__init__.py abs}}";
277 pattern = [ "src/engine/*Tests.py" ];
278 body = "${read_file ${source template/Tests.py abs}}";
281 pattern = [ "src/engine/*.py" ];
282 body = "${read_file ${source template/file.py abs}}";
285 pattern = [ "test/*.py" ];
286 body = "${read_file ${source template/test.py abs}}";
291 * Command for distributing changes from Aegis to all of the repositories
292 * we want to mirror the information.
294 * XXX Uncomment after upgrading to an Aegis version that supports this.
296 integrate_pass_notify_command =
297 "$sh ${s bin/scons-cdist} -p $project $change";