In the wake of Rain adding a common directory to the tree (which almost
gave me a heart attack I might add) I suspect it's probably a good time to
suggest code layouts and talk about the base lib (twilight.a, eventually
libtwilight.so/twilight.dll as well, but not today..)

After talking things over with mercury, I'm convinced that we're going to
have more subdirs than I previously anticipated.  Here's the way things
will start out:

twilight
 |-- doc
 |-- nq
 |-- qw
 |-- qw-server
 |-- src
 |    |-- base
 |    |-- libpng
 |    |-- renderer
 |    |-- sound
 |    \-- zlib
 \-- tools

The reason for this is that our twilight directory is getting crowded and
will probably continue to become more so.  Here's what mine looks like
right now:

  AUTHORS     NEWS         config.guess@  gamecode/      src/
  COPYING     README       config.log     include/       tools/
  COPYING.BSD THANKS       config.status* install-sh@    twilight.dsw
  CVS/        TODO         config.sub@    missing@       twilight.spec
  INSTALL@    acconfig.h   configure*     mkinstalldirs@ twilight.spec.in
  Makefile    aclocal.m4   configure.in   nq/
  Makefile.am autogen.sh*  debian/        qw/
  Makefile.in config.cache doc/           qw-server/

Now if the number of files in there is likely to go up and not down, we
really don't want to have a bunch of subdirs in the way as well!  You'll
note I already have a src directory above.  I will add most of the above
structure to the tree as soon as I know if someone's going to scream about
it.  =)


Now the eventual goal here is to remove the three nq, qw, and qw-server
dirs from the root directory and move them into src.  That's trivial and I
could do it overnight much to Vic/Coderjoe's annoyance as they have to
rewrite the damned project files to cope.  But we won't do that to them
yet.  Essentially, as we have need of things we'll add them to break the
code into logical, managable chunks.

Some ground rules I'd like to set for these things if nobody objects...

 - if you have a choice between making a piece of code not depend on
   another piece and merging it into one of the above already specified
   dirs, please make the code independant!  This applies particularly to
   parts of the sound code and renderer which may be tied to network
   details, but should have their own private contexts which are updated
   by the engines from the network and whatnot.

 - stuff in src/base may not depend on other parts of the engine.  This
   code is intended to eventually be used as-is by tools which will link
   it dynamically.  They aren't going to be the full game, and they're not
   expected to have to jump through hoops to use the Zone, pak files, etc.

 - prefixes were used on most of the files which were not considered to be
   generally self-contained.  Sound code is found with snd_, renderer code
   is gl_r (or for our purposes, I consider gl_draw, gl_screen, and view
   to be part of the renderer as well..  sbar's a tossup, but my gut says
   no.) Generally once these files move to their own directory, THAT is
   their prefix.  renderer/r_ or renderer/gl_r is overkill and therefore
   should be killed.  =)

 - nq/, qw/, and qw-server/ will remain in twilight/ until we've finished
   tearing stuff out of them.  The one exception is qw-server, which will
   probably partway through this take up residence in qw/, probably as
   soon as the base lib works and all.  Once we're done merging the stuff
   we want to merge, we'll move them to src as well, to make it so there's
   less stuff for our porters to rewrite all at once.  It'll also maintain
   a better CVS history this way.

 - one source, one object.  This is truly important to us unix guys who
   have to make many nasty and evil hacks to our build system that some of
   us don't know how to make and others of us just don't want to make.
   This requires a little creativity, but the result is often better for
   it, see the new global callback in cvar.c to avoid the info flag
   handling which is specific to each of our three targets.  The way to do
   it which avoided an ifdef gives us the ability to use cvar.c in stuff
   we never before dreamed about!

 - stick the sources with the headers.  I don't personally mind if there
   is a render.h or sound.h for all of the functions in a directory when
   that is appropriate, but with the exception of src/base, the headers
   should stay in the directory with their .c files.  include/ is reserved
   space for those things only.

-- 
Joseph Carter <[EMAIL PROTECTED]>            Free software developer

<|Rain|> I *love* SWB!!
<|Rain|> Or, press 5 to speak to a representitive..
<|Rain|> *5*
<|Rain|> You are being transferred, please hold...
<|Rain|> ...
<|Rain|> ...
<|Rain|> We're sorry, this number can not be completed as dialed.
<|Rain|> Please check the number and try again.

Attachment: msg00833/pgp00000.pgp
Description: PGP signature

Reply via email to