[CF-Devel] Umm

Mark Wedel mwedel at scruz.net
Sun Apr 22 22:24:47 CDT 2001


dnh wrote:
>
     
     
     >
     
      Could someone please send an email explaining exactly;
     
     >
     
     
     >
     
      a) how one 'collects arches'
     
     >
     
      b) when one should 'collect arches'
     
     >
     
      c) what to avoid when 'collecting arches'
     
     >
     
      d) the reason for 'collecting arches'
     
     
 Note:  I use 'you' a lot in the message below, but this meant as a general
term, and not you as in darth bob.


 Requirements to collect the archetypes:

1) Have a copy of the server installed on your system.
2) In the lib directory of the server source, have the 'arch' directory
available.  Available here means that either this is the location of the arch
distribution (ie, where you unpacked it), or is a symlink (ln -s ... ...) to
where you have unpacked/cvs checkout the arch directory.

 To answer your questions:

a) From the lib directory described above, type 'rm archetypes; make'.  This
should do the right thing.
b) Simple answer is anytime you change entries in the arch tree, you need to
collect them and then install them to take effect.  In terms of CVS, whenever
changes are made to the arch tree, after the changes are verified to work, you
should collect the archs and check them into CVS (so for example, remote sites
only need to checkout/update the server, and not have to check out the arch's
and rebuild for their own seerver.

 Note that collecting the archs does not mean your local server (or in the case
of a cvs update) will necessarily use them.  You still need to do a make install
for the arch's (and images) to get copied to where the server expects to find
them.  The one exception to this case is if you have set up your crossfire
installation such that the install directory is the same as your working
directory.

c) Bugs.  As with all checkins to CVS, it should be verified there are no bugs
in the built archs.  This is hard to test 100%, as the definition of a bug can
very (ie, if some monster is worth too much exp, that may be a bug, but not
really the type I am thinkg of here).  What I am thinking of here are things
like typos, bad reference to other items (ie, randomitems, other_arch, face,
...).  Most of the last case will be caught by crossfire when it runs, so watch
the output of the server at startup to see if it complains about missing
archs/faces or other things.

 Note that a collect of the arch and testing as described above should be done
even when just changing the the individual .arc file.  After all, some servers
may have added their custom archs, and hence rebuild them on a regular basis, so
checking in a bad .arc file will still mess them up, even if you haven't checked
in a collected version.  Or similarly, perhaps someone else has done a cvs
update of their arch directory and grabbed your changes, and made some other
changes they are committing, and do run the collect process - even though their
arc's may be find, your arch's would still cause problems in the collected
version.

 Also, if you are collecting and checking in images, make sure you don't collect
the alternate image set and check those in (crossfire.png).  this will happen if
you have a alternate_image directory/symlink in your lib directory that contains
images.

d) see answeer to b above.  Basically, if you don't collect them, someone will
have to at some point in order to use them.  the arch tree is not used at all by
the server - its existance is to make editing and find files easier.  

 Now this doesn't need to be done for every change you make.  For example, if
you change 5 things, and you know you are going to change 5 more things
tomorrow, you could just wait until then to run the collect.  But then by the
same token, you should probably wait until then before you run a commit in the
arch directory, and commit all 10 at the same time.

 Now it would be possible for someone to set up a cron job that does an make
collect each night, and if any of the relevant files are different,
automatically commit them.  In this case, when you make a change to the arch
directory, youu wouldn't need to run the collect - the nightly collect process
would do that for you (and all other developers).  OTOH, the creation of such a
script is more than just a make collect, cvs commit - some sanity checking
should also be done to make sure that make collect did not have errors, that the
output files are in fact intact (and not truncated for any of a variety of
reasons), etc.

    
    


More information about the crossfire mailing list