[DGD]DGD extension interface, some thoughts

[Michael Bergbauer]

On 26-Sep-2000 Felix A. Croes wrote:
> John "West" McKenna <john at ucc.gu.uwa.edu.au> wrote:
> 
>> >At initialization time, a specific function will be called to
>> >initialize external modules.  By default, this function will exist
>> >in dgd/src/config.c and do nothing.  Module writers should supply
>> >their own version of this function.  The preferred method will be
>> >to comment it out in config.c, and link DGD with additional module
>> >code at compile time.  Replacing the function will be the only
>> >change that has to be made to the source code of DGD itself.
>>
>> I assume you're working out a cleaner method of adding extensions like
>> the networking package.  If there's a single function that gets called,
>> and packages over-write its definition, what happens when there is more
>> than one package?
> 
> I hereby (arbitrarily) rule that to redefine a kfun more than once
> is an error.

That's not the point, Felix:

what happens if I install two packets, that each defines one new kfun? Then I
have two config-functions. That is what John wanted to point out, if I got it
correct (if not, then I'll point it out ;))

We really should find a better method then just redefining one method, because
you otherwise, you always have to tweak around in the sources when adding an
additional module, and noone will benefit of it. It should make installing new
packets easier (than the current patch method!), and not more compilcated.
 
>> A better way might be to have the installation process write the config.c
>> file itself, based on the contents of an "extensions" directory (does
>> this sound familiar?).  It would undoubtedly be a pain to implement,
>> considering the range of ports that must be supported.
> 
> I am not interested in resolving conflicts between different packages.
> I will just offer an interface by which DGD can be extended, and the
> rest is for the package writers to work out.

Thats right, thats not your task, but there are a few things that can be done
to make it more comfortable:

Lets say, all packages are places in subdirs of /src/ext, together with their
own makefiles, that define the various targets that are needed for compiling,
linking, cleanup and so on. The main makefile now just should be able to create
another file that defines the initialisation function. This init-function just
calls a function <dir>_init() for each subdir in /src/ext. A small perlscript
should do that task, i'm sure. 


Michael

-- 
Michael Bergbauer <michael.bergbauer at gmx.net>
Use your idle CPU cycles.
See http://www.distributed.net and win $ 1 000.
Visit our mud Geas at geas.franken.de Port 3333

List config page:  http://list.imaginary.com/mailman/listinfo/dgd