# [SERVER] proposal for extensions.c

ThwartedEfforts (abakun@scinc.com)
Mon, 18 Mar 1996 14:53:03 PST

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    Richard Godard and I have been talking about how to easily allow people to
    distribute extensions to the MOO server so that the amount of file editing
    that needs to be done is kept to a minium.  Here is what we've come up with.

    Extensions, usually defined as being new builtin functions, to the MOO
    server should be distributed as a single tar file.  The tar file should contain:

    1)  a README.extension-name, telling people about the extensions.
    2)  a file ending in .ext, which contains the C code for the extensions.
    3)  other required header files, if necessary.

    In order to make this easy to keep track of, extensions of different types
    should not be distributed via the same tar file.  For example, if I
    distribute a series of list manipulation functions, they should not be
    bundled with file manipulation functions.

    For example, I make an extension called 'foofunc':
    % tar -tvf foofunc.tar
    -rw-r--r--   1 abakun/users          83 Mar 18 13:42 README.foofunc
    -rw-r--r--   1 abakun/users       10240 Mar 18 14:14 foofunc.c.ext

    The contents of README.foofunc
    ---
    The foofunc extension adds a function called foo() to the LambdaMOO v1.8.x
    server.  When foo() is called, it creates a generic foobar for the named
    player and moves it to their contents.

    To add the function foo() to your LambdaMOO server:

    Add this line to extensions.c near the top with the rest of the includes:
    #include "foofunc.c.ext"

    Add this line to the register_extensions function near the end of extensions.c:
       (void) register_foofunc();

    Remake the server, reboot your MOO, and enjoy the added functionality
    provided by the foo() function.
    (Note: You might have to remove extensions.o)
    ---

    The contents of foofunc.c.ext would be pure C code, ready for in-lineing in
    extensions.c via #include:
    ---
    /* foofunc.c.ext copytight ThwartedEfforts */
    /* Not loose, it's tight! */

    #include "utils.h"
    #include "bf_register.h"
    #include "functions.h"

    static package
    bf_foo(Var arglist, Byte next, void *vdata, Objid progr)
    {
      do_various_foo_related_stuff();
    }

    void register_foofunc(void)
    {
      /* oklog("registering foofunc()"); */
      (void) register_function("foo", 1, 1, bf_foo, TYPE_OBJ);
    }

    /* end of foofunc.c.ext */
    ---

    This keeps all editing required to add a new extensions to be done in
    extensions.c; no editing the makefile, no cutting and pasting of code from
    the foofunc.c.ext file to extensions.c, etc.

    Assuming you have a smart 'make', this should be all there is to it (might
    need to remove extensions.o, and, as was previously pointed out, 'make
    depend' could come in handy.).  I have two things to do, both localized to
    extensions.c.  Of course, the foofunc.c.ext file should be in the same
    directory as extensions.c (and the rest of the server source).  I considered
    suggesting that the extensions be put in another dir under the main MOO
    source dir, but that seems like overkill.

    The reason I choose the .ext extension on extension files is so that you
    easily pick out which files are needed for the MOO to compile standard, and
    which files are extensions.  I've tested this on a few preprocessors, none
    seem to have a problem with non-standard extensions (well, ideally, they
    shouldn't).  Should prefixes (a la ext-foofunc.c) be used instead?

    Obviously, foofunc.c.ext and other extension files should #include the
    necessary header files they need to reference functions from within themselves.

    Patches to the server in general are still best distributed as patch files,
    to be applied with the patch command.  Extensions.c should never be patched.

    Comments? Flames?

    Andy