summaryrefslogtreecommitdiffstats
path: root/config
diff options
context:
space:
mode:
authorSteven Knight <knight@baldmt.com>2001-07-06 11:46:17 (GMT)
committerSteven Knight <knight@baldmt.com>2001-07-06 11:46:17 (GMT)
commit11ad88ce6d9165bebc6752a120bce4d962368bbf (patch)
tree231b89344132f163250b4799a8aa69628dd0bb35 /config
downloadSCons-11ad88ce6d9165bebc6752a120bce4d962368bbf.zip
SCons-11ad88ce6d9165bebc6752a120bce4d962368bbf.tar.gz
SCons-11ad88ce6d9165bebc6752a120bce4d962368bbf.tar.bz2
Initial revisionstart
Diffstat (limited to 'config')
-rw-r--r--config264
1 files changed, 264 insertions, 0 deletions
diff --git a/config b/config
new file mode 100644
index 0000000..c36eaf0
--- /dev/null
+++ b/config
@@ -0,0 +1,264 @@
+/*
+ * 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 = "cons date='${DAte %Y/%m/%d %H:%M:%S}' developer=${DEVeloper} version=${VERsion}";
+
+/*
+ * 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;
+
+/*
+ * NOT UNTIL AEGIS 3.23; we may not need it anyway.
+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 runtest.py -v ${VERsion} ${File_Name}";
+
+/*
+ *
+ */
+file_template =
+[
+ {
+ pattern = [ "src/scons/*__init__.py" ];
+ body = "${read_file ${source template/__init__.py abs}}";
+ },
+ {
+ pattern = [ "src/scons/*Tests.py" ];
+ body = "${read_file ${source template/test.py abs}}";
+ },
+ {
+ pattern = [ "src/scons/*.py" ];
+ body = "${read_file ${source template/file.py abs}}";
+ },
+];