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 = "python ${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.
59 link_integration_directory = true;
63 * This is set temporarily to allow us to build using the SCons
64 * currently checked in to the src directory.
65 create_symlinks_before_build = true;
69 * aegis - project change supervisor
70 * This file is in the Public Domain, 1995, 1998 Peter Miller.
72 * MANIFEST: example of using rcs in the project config file
74 * The entries for the commands are listed below. RCS uses a slightly
75 * different model than aegis wants, so some maneuvering is required.
76 * The command strings in this section assume that the RCS commands ci and co
77 * and rcs and rlog are in the command search PATH, but you may like to
78 * hard-wire the paths, or set PATH at the start of each. You should also note
79 * that the strings are always handed to the Bourne shell to be executed, and
80 * are set to exit with an error immediately a sub-command fails.
82 * In these commands, the RCS file is kept unlocked, since only the owner will
83 * be checking changes in. The RCS functionality for coordinating shared
84 * access is not required.
86 * One advantage of using RCS version 5.6 or later is that binary files are
87 * supported, should you want to have binary files in the baseline.
89 * The ${quote ...} construct is used to quote filenames which contain
90 * shell special characters. A minimum of quoting is performed, so if
91 * the filenames do not contail shell special characters, no quotes will
96 * This command is used to create a new file history.
97 * This command is always executed as the project owner.
98 * The following substitutions are available:
101 * absolute path of the source file
103 * absolute path of the history file
105 * The "ci -f" option is used to specify that a copy is to be checked-in even
106 * if there are no changes.
107 * The "ci -u" option is used to specify that an unlocked copy will remain in
109 * The "ci -d" option is used to specify that the file time rather than the
110 * current time is to be used for the new revision.
111 * The "ci -M" option is used to specify that the mode date on the original
112 * file is not to be altered.
113 * The "ci -t" option is used to specify that there is to be no description
114 * text for the new RCS file.
115 * The "ci -m" option is used to specify that the change number is to be stored
116 * in the file log if this is actually an update (typically from aenf
117 * after aerm on the same file name).
118 * The "rcs -U" option is used to specify that the new RCS file is to have
120 * The "rcs -kk" option is used to specify that keyword substitution is
121 * disabled (only keyword names, not values, are substituted).
123 history_create_command =
124 "ci -f -u -d -M -m$c -t/dev/null ${quote $input} ${quote $history,v}; \
125 rcs -kk -U ${quote $history,v}";
129 * This command is used to get a specific edit back from history.
130 * This command is always executed as the project owner.
131 * The following substitutions are available:
134 * absolute path of the history file
136 * edit number, as given by history_\%query_\%command
138 * absolute path of the destination file
140 * The "co -r" option is used to specify the edit to be retrieved.
141 * The "co -p" option is used to specify that the results be printed on the
142 * standard output; this is because the destination filename will never
143 * look anything like the history source filename.
144 * The "rcs -kk" option is used to specify that keyword substitution is
145 * disabled (only keyword names, not values, are substituted).
147 history_get_command =
148 "co -kk -r${quote $edit} -p ${quote $history,v} > ${quote $output}";
151 * This command is used to add a new "top-most" entry to the history file.
152 * This command is always executed as the project owner.
153 * The following substitutions are available:
156 * absolute path of source file
158 * absolute path of history file
160 * The "ci -f" option is used to specify that a copy is to be checked-in even
161 * if there are no changes.
162 * The "ci -u" option is used to specify that an unlocked copy will remain in
164 * The "ci -d" option is used to specify that the file time rather than the
165 * current time is to be used for the new revision.
166 * The "ci -M" option is used to specify that the mode date on the original
167 * file is not to be altered.
168 * The "ci -m" option is used to specify that the change number is to be stored
169 * in the file log, which allows rlog to be used to find the change
170 * numbers to which each revision of the file corresponds.
172 * It is possible for a a very cautious approach has been taken, in which case
173 * the history_put_command may be set to the same string specified above for
174 * the history_create_command.
176 history_put_command =
177 "ci -f -u -d -M -m$c ${quote $input} ${quote $history,v}";
180 * This command is used to query what the history mechanism calls the top-most
181 * edit of a history file. The result may be any arbitrary string, it need not
182 * be anything like a number, just so long as it uniquely identifies the edit
183 * for use by the history_get_command at a later date. The edit number is to
184 * be printed on the standard output. This command is always executed as the
187 * The following substitutions are available:
190 * absolute path of the history file
192 history_query_command =
193 "rlog -r ${quote $history,v} | awk '/^head:/ {print $$2}'";
196 * RCS also provides a merge program, which can be used to provide a three-way
197 * merge. It has an ouput format some sites prefer to the fmerge output.
199 * This command is used by aed(1) to produce a difference listing when a file
200 * in the development directory is out of date compared to the current version
203 * All of the command substitutions described in aesub(5) are available.
204 * In addition, the following substitutions are also available:
207 * The absolute path name of a file containing the common ancestor
208 * version of ${MostRecent} and {$Input}. Usually the version originally
209 * copied into the change. Usually in a temporary file.
211 * The absolute path name of a file containing the most recent version.
212 * Usually in the baseline.
214 * The absolute path name of the edited version of the file. Usually in
215 * the development directory.
217 * The absolute path name of the file in which to write the difference
218 * listing. Usually in the development directory.
220 * An exit status of 0 means successful, even of the files differ (and they
221 * usually do). An exit status which is non-zero means something is wrong.
223 * The "merge -L" options are used to specify labels for the baseline and the
224 * development directory, respecticvely, when conflict lines are inserted
226 * The "merge -p" options is used to specify that the results are to be printed
227 * on the standard output.
232 merge -p -L baseline -L C$c ${quote $mostrecent} ${quote $original} \
233 ${quote $input} > ${quote $output}; \
238 diff -c ${quote $original} ${quote $input} > ${quote $output}; \
242 * We use a runtest.pl script to execute tests. This takes care of
243 * massaging environment variables and the like to test against the
244 * unpacked package in the current directory.
246 * Note that we must include $spe in the batch_test_command line (so
247 * that Aegis thinks we're smart about testing ourselves against the
248 * baseline) but we don't actually need it. Our tests always run
249 * relative to the package built under the current directory, which
250 * is set appropriately during a baseline test. So we just use the
251 * proper aesub variable to comment out the expanded $spe.
253 test_command = "python ${Source runtest.py Absolute} -p tar-gz -q ${File_Name}";
255 batch_test_command = "python ${Source runtest.py Absolute} -p tar-gz -o ${Output} ${File_Names} ${COMment $spe}";
257 new_test_filename = "test/CHANGETHIS.py";
265 pattern = [ "src/engine/*__init__.py" ];
266 body = "${read_file ${source template/__init__.py abs}}";
269 pattern = [ "src/engine/*Tests.py" ];
270 body = "${read_file ${source template/Tests.py abs}}";
273 pattern = [ "src/engine/*.py" ];
274 body = "${read_file ${source template/file.py abs}}";
277 pattern = [ "test/*.py" ];
278 body = "${read_file ${source template/test.py abs}}";