MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

[SERVER] proposal for extensions.c

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
Follow-Ups:
Home | Subject Index | Thread Index