[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Adding more external libraries to avram
is currently a manual
procedure requiring the attention of a developer conversant with C.
To support a new library called foobar
,
these steps need to be followed at a minimum.
extern list avm_foobar_call (list function_name,list argument, int *fault); extern list avm_have_foobar_call (list function_name,int *fault); extern void avm_initialize_foobar (); extern void avm_count_foobar (); |
There should also be the usual preprocessor directives for ‘include’ files. The naming convention shown should be followed in anticipation of automated support for these operations in the future.
aclocal \ && automake --gnu --add-missing \ && autoconf |
This command requires having automake
and
autoconf
installed on your system.
#include<avm/foobar.h>
after the
other include
directives.
"foobar"
to the end of the array of
libnames
in avm_initialize_libfuns
.
avm_initialize_foobar
to the body.
avm_count_foobar
to the body of
avm_count_libfuns
.
case nn: return avm_foobar_call(function_name,argument,fault); |
after the last case in avm_library_call
, being
careful not to change the order, and using the same
name as above in the file ‘foobar.h’.
case nn: looked_up = avm_have_foobar_call(function_name,fault); break; |
after the last case in avm_have_library_call
, being
careful not to change the order, and using the same name
as above in the file ‘foobar.h’.
make
.
The functions shown above have the obvious interpretations, namely
that avm_foobar_call
evaluates a library function from the
foobar
library, and avm_have_foobar_call
tests for a
function’s availability. The latter should interpret wild cards as
explained in Calling existing library functions, but should
return only a list of strings for the matching function names rather
than a list of pairs of strings, as the library name is redundant.
The remaining functions are for static initialization and reclamation.
These functions should consist mainly of boilerplate code similar to
the corresponding functions in any of the other library source files,
which should be consulted as examples. The real work would be done by
other functions called by them. These should be statically declared
within the ‘.c’ source file and normally not listed in the
‘.h’ header file unless there is some reason to think they may be
of more general use. Any externally visible functions should have
names beginning with avm_
to avoid name clashes.
Some helpful hints are reported below for what they may be worth.
foobar.c
should contain only glue
code for library routines developed elsewhere with great skill rather
than reinventing them in some home grown way.
nm
on the static
library file to find out the real names of the functions and
c++filt
to find out which is which. However, there
is no obvious workaround for the use of so called derived classes
by C++ programmers to simulate passing functions as parameters.
avram
. Typical design flaws are
stderr
or
stdout
that are unfit for end user consumption
malloc
fails
Some of these misfeatures have workarounds as explained next in Working around library misfeatures, at least if there’s nothing else wrong with the library.
Those who support avram
are always prepared to assist in the
dissemination of worthwhile contributed library modules under terms
compatible with GNU GENERAL PUBLIC LICENCE, and under separate copyrights if
preferred. Contributed modules can be integrated into the official
source tree provided that they meet the following additional
guidelines to those above.
autoconf
macros and conditional defines
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated on November 8, 2012 using texi2html 1.82.