config

   1 /*
   2  * MANIFEST: use of SCons in project config file to build itself
   3  *
   4  * SCons has a Repository feature, introduced in SCons 0.09, that was
   5  * designed to work well with Aegis.
   6  */
   7
   8 /*
   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
  11  * the rules.
  12  *
  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
  16  * baselines.
  17  *
  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.
  23  *
  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.
  29  *
  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
  40  * recognize them.
  41  *
  42  * The ${Source bootstrap.py} substitution finds bootstrap.py wherever
  43  * it may be in the Aegis baselines.
  44  *
  45  * The long -Y${SUBSTitute...} substitution takes the Aegis baseline
  46  * search path and turns it into the right -Y command-line options for
  47  * SCons.
  48  *
  49  * The rest of the substitutions (${DEVeloper}, etc.) should be obvious.
  50  *
  51  * Look in aesub(5) for more information about command substitutions.
  52  */
  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}";
  54
  55 /*
  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  */
  60
  61 link_integration_directory = true;
  62
  63 /*
  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;
  67  */
  68
  69 /*
  70  *      aegis - project change supervisor
  71  *      This file is in the Public Domain, 1995, 1998 Peter Miller.
  72  *
  73  * MANIFEST: example of using rcs in the project config file
  74  *
  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.
  82  *
  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.
  86  *
  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.
  89  *
  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
  93  * be used.
  94  */
  95
  96 /*
  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:
 100  *
 101  * ${Input}
 102  *      absolute path of the source file
 103  * ${History}
 104  *      absolute path of the history file
 105  *
 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
 109  *      the baseline.
 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
 120  *      unstrict locking.
 121  * The "rcs -kk" option is used to specify that keyword substitution is
 122  *      disabled (only keyword names, not values, are substituted).
 123  */
 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}";
 127
 128
 129 /*
 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:
 133  *
 134  * ${History}
 135  *      absolute path of the history file
 136  * ${Edit}
 137  *      edit number, as given by history_\%query_\%command
 138  * ${Output}
 139  *      absolute path of the destination file
 140  *
 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).
 147  */
 148 history_get_command =
 149         "co -kk -r${quote $edit} -p ${quote $history,v} > ${quote $output}";
 150
 151 /*
 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:
 155  *
 156  * ${Input}
 157  *      absolute path of source file
 158  * ${History}
 159  *      absolute path of history file
 160  *
 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
 164  *      the baseline.
 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.
 172  *
 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.
 176  */
 177 history_put_command =
 178         "ci -f -u -d -M -m$c ${quote $input} ${quote $history,v}";
 179
 180 /*
 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
 186  * project owner.
 187  *
 188  * The following substitutions are available:
 189  *
 190  * ${History}
 191  *      absolute path of the history file
 192  */
 193 history_query_command =
 194         "rlog -r ${quote $history,v} | awk '/^head:/ {print $$2}'";
 195
 196 /*
 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.
 199  *
 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
 202  * in the baseline.
 203  *
 204  * All of the command substitutions described in aesub(5) are available.
 205  * In addition, the following substitutions are also available:
 206  *
 207  * ${ORiginal}
 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.
 211  * ${Most_Recent}
 212  *      The absolute path name of a file containing the most recent version.
 213  *      Usually in the baseline.
 214  * ${Input}
 215  *      The absolute path name of the edited version of the file.  Usually in
 216  *      the development directory.
 217  * ${Output}
 218  *      The absolute path name of the file in which to write the difference
 219  *      listing.  Usually in the development directory.
 220  *
 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.
 223  *
 224  * The "merge -L" options are used to specify labels for the baseline and the
 225  *      development directory, respecticvely, when conflict lines are inserted
 226  *      into the result.
 227  * The "merge -p" options is used to specify that the results are to be printed
 228  *      on the standard output.
 229  */
 230
 231 diff3_command =
 232         "set +e; \
 233 merge -p -L baseline -L C$c ${quote $mostrecent} ${quote $original} \
 234 ${quote $input} > ${quote $output}; \
 235 test $? -le 1";
 236
 237 /*
 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.
 242  */
 243
 244 diff_command =
 245         "set +e; \
 246         diff -a -c ${quote $original} ${quote $input} > ${quote $output}; \
 247         test $? -le 1";
 248
 249 /*
 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.
 253  *
 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.
 260  */
 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}";
 262
 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}";
 264
 265 new_test_filename = "test/CHANGETHIS.py";
 266
 267 /*
 268  *
 269  */
 270 file_template =
 271 [
 272         {
 273                 pattern = [ "src/engine/*__init__.py" ];
 274                 body = "${read_file ${source template/__init__.py abs}}";
 275         },
 276         {
 277                 pattern = [ "src/engine/*Tests.py" ];
 278                 body = "${read_file ${source template/Tests.py abs}}";
 279         },
 280         {
 281                 pattern = [ "src/engine/*.py" ];
 282                 body = "${read_file ${source template/file.py abs}}";
 283         },
 284         {
 285                 pattern = [ "test/*.py" ];
 286                 body = "${read_file ${source template/test.py abs}}";
 287         },
 288 ];
 289
 290 /*
 291  * Command for distributing changes from Aegis to all of the repositories
 292  * we want to mirror the information.
 293  *
 294  * XXX Uncomment after upgrading to an Aegis version that supports this.
 295
 296 integrate_pass_notify_command =
 297         "$sh ${s bin/scons-cdist} -p $project $change";
 298  *
 299  */