chiark / gitweb /
Bring CGI docs pretty much up to date
[disorder] / README.developers
index f7d9cfd5d6654977c0b31d28f04a876c716e1eae..5a5dd8908acba9035dc3aea11ccc4f3d2d9ffbd9 100644 (file)
@@ -14,6 +14,20 @@ Dependencies:
                     libao-dev libmad0-dev libasound2-dev libdb4.3-dev \
                     libflac-dev
 
+   * On FreeBSD you'll need at least these packages:
+        autotools
+        bash
+        flac
+        mad
+         boehm-gc
+         db43
+         gmake
+         gsed
+         libao
+         libgcrypt
+         wget
+         vorbis-tools
+
    * Please report unstated dependencies (here, README or debian/control).
 
 Building:
@@ -21,7 +35,8 @@ Building:
    * Compiled versions of configure and the makefiles are including in bzr, so
      if you didn't use a source tarball, you must start as follows:
 
-        bash ./prepare -C
+        bash ./prepare
+        ./configure -C
         make
 
    * On FreeBSD you must use gmake.
@@ -64,10 +79,13 @@ APIs And Formats:
 The Server:
 
    * The server's command implementations must not block.  Waiting for a little
-     disk IO is OK but blocking on long-lasting transactions or external
-     resources is not acceptable.  Long-running subprocesses should use
-     subprograms (rather than forking but not execing) if reasonably possible;
-     see c_stats() for an example.  c_reminder() is probably in the grey area.
+     disk IO is OK but blocking for extended periods on long-lasting
+     transactions or external resources is not acceptable; it will wedge the
+     server for all other users.
+
+     Long-running subprocesses should use subprograms (rather than forking but
+     not execing) if reasonably possible; see c_stats() for an example.
+     c_reminder() is probably in the grey area.
 
    * The server process does not use threads and I would like to keep it that
      way.
@@ -117,7 +135,8 @@ The Server:
 Web Interface:
 
    * The web interface does not use Javascript or Flash and I would like to
-     keep it that way.
+     keep it that way.  Clever use of CSS is OK provided it works well on the
+     mainstream browsers.
 
    * I know that the web template syntax is rather nasty.  Perhaps it will be
      improved in a future version.
@@ -140,13 +159,24 @@ Disobedience:
 
    * Update doc/disobedience.1.in for any changes you make.
 
+New Platforms:
+
+   * It is not mandatory to have an entry in configure's 'case $host' section,
+     but may well be convenient.
+
+   * Complete support for a new platform implies updating scripts/setup.in and
+     scripts/teardown.in as well as getting the software to build and work (but
+     this doesn't mean that patches that don't achieve this will be rejected).
+
 Code And Patches:
 
    * Please follow the existing layout conventions.
 
    * Please try to write doc comments for new functions, types, etc using the
      same syntax as the existing ones.  Doxygen can be used to turn this into
-     reference documentation.
+     reference documentation (see http://www.stack.nl/~dimitri/doxygen/) but
+     really the point is to have good inline code documentation, not the
+     Doxygen output as such.
 
    * More importantly, new configuration directives, protocol commands,
      interface features etc should be documented in the relevant places.
@@ -158,6 +188,13 @@ Code And Patches:
      (But if your new feature only makes sense on a given platform then
      obviously its new dependencies don't need to be available elsewhere.)
 
+   * GCC is stated as a dependency.  In fact the code is mostly standard C,
+     with C99 initializers, long long and possibly the occasional // comment as
+     the main departures from C89.  Additional GCCisms will be accepted if it's
+     impractical to avoid them.  At least one active user is still using GCC
+     2.95, so extensions that only appear in later versions are to be avoided
+     for the time being.
+
    * Please submit patches either using 'diff -u', or by publishing a bzr
      branch somewhere I can get at it.