/* -*-c-*-
 *	aegis - project change supervisor
 *	This file is in the Public Domain, 1995, 1998 Peter Miller.
 *      Changes to it Copyright 2003, John Darrington
 *
 * 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 contain 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.
 */
history_create_command =
	"ci -f -u -d -M -m$c -t/dev/null ${quote $input} ${quote $history,v}; \
rcs -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.
 */
history_get_command =
	"co -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 output 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, respectively, 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.
 */

merge_command =
	"set +e; \
merge -p -L baseline -L C$c ${quote $mostrecent} ${quote $original} \
${quote $input} > ${quote $output}; \
test $? -le 1";
/*
 *	aegis - project change supervisor
 *	This file is in the Public Domain, 1999 Peter Miller.
 *
 * MANIFEST: example use of diff in the project config file
 *
 * 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 contain shell special characters, no quotes will
 * be used.
 */


/*
 * Compare two files using GNU diff.  The -U 10 option produces an output
 * with inserts and deletes shown line, with 10 lines of context before
 * and after.  This is usually superior to -c, as it shows what happened
 * more clearly (and it takes less space).  The -b option could be added
 * to compare runs of white space as equal.
 *
 * This command is used by aed(1) to produce a difference listing when
 * file in the development directory was originally copied from 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 version
 *	originally copied.  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.  (So we need to massage the exit status, because diff does
 * things a little differently.)
 *
 * The non-zero exit status may be used to overload this command with
 * extra tests, such as line length limits.  The difference files must
 * be produced in addition to these extra tests.
 */
diff_command ="$sh ${s check_cdate.sh} $input 'Copyright .*${date %Y}'; set +e; diff -U10 ${quote $original} ${quote $input} > ${quote $output}; test $? -le 1";
/*
 *	aegis - project change supervisor
 *	This file is in the Public Domain, 1995, Peter Miller.
 *
 * MANIFEST: example use of cook 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,
 * available by anonymous FTP from your nearest GNU archive site.  GNU Make was
 * chosen because it was the most powerful, it is widely available (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 full 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 ="rm -f src/vers.c ; make -f ${s Smake } project=$p change=$c";

development_build_command ="make -f ${s Smake } project=$p change=$c";


/*
 * 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 baseline.  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;


/*
 * This field is used to set the command to be executed by the aet(1)
 * command.  Defaults to "$shell  $file_name" if not set. 

 * All of the substitutions described in aesub(5) are  available.  In
 * addition: 

 * ${File_Name}
 * The absolute path of the test to be executed.

 * Note that tests are source files, and thus never  have the execute bit set.

*/


history_put_trashes_file = warn;

development_directory_template = "$ddd/${left ${proj trunk_name} ${expr ${namemax $ddd} - ${length $magic} + ${length $magic} - ${length -$vers}}}-$vers";


file_template = [
  {
		 pattern = [ "*.cc","*.c" ] ;
		 body = "${read_file ${s c_template a}}";
  },
  {
		 pattern = [ "*.hh","*.h" ] ;
		 body = "${read_file ${s h_template a}}";
  },
  {
		 pattern = [ "*.l", "*.y" ] ;
		 body = "${read_file ${s l_template a}}";
  },
  {
		 pattern = [ "test/*/*.sh" ];
		 body = "${read_file ${s test_template a}}";
  }
];
