Next: How It All Works, Previous: Data Structures, Up: Top
A good deal of interface code is automatically generated by the mk-src.pl Perl script. I am doing it this way to avoid having to write a lot of relative code for the C++ interface. This should also make adding interface for other languages a lot less tedious and will allow the interface to automatically take advantage of new Aspell functionality as it is made available. The mk-src.pl script uses mk-src.in as its input.
NOTE: This section may not always be up to date since it is manually converted from the pod source.
The format of mk-src.in is as follows:
    The following characters are literals: { } / '\ ' \n = >
    <items>
    <items> := (<item>\n)+
    <items> := <category>:\ <name> {\n<details>\n} | <<tab>><details>
    <details> := <options>\n /\n <items>
    <options> := (<option>\n)*
    <option> := <key> [=> <value>]
    <<tab>> means everything should be indented by one tab
   See MkSrc::Info for a description of the categories and options
%info
   
The info array contains information on how to process the info in mk-src.pl. It has the following layout
    <catagory> => options => [] 
                  groups => [] # if undef than anything is accepted
                  creates_type => "" # the object will create a new type
                                     # as specified
                  proc => <impl type> => sub {}
    where <impl type> is one of:
    cc: for "aspell.h" header file
    cxx: for C++ interface implemented on top of cc interface
    native: for creation of header files used internally by aspell
    impl: for defination of functions declared in cc interface.
          the definations use the native hedaer files
    native_impl: for implementations of stuff declared in the native
                  header files
    each proc sub should take the following argv
    $data: a subtree of $master_data
    $accum: 
    <options> is one of:
    desc: description of the object
    prefix:
    posib err: the method may return an error condition
    c func:
    const: the method is a const member
    c only: only include in the external interface
    c impl headers: extra headers that need to be included in the C impl
    c impl: use this as the c impl instead of the default
    cxx impl: use this as the cxx impl instead of the default
    returns alt type: the constructor returns some type other than
      the object from which it is a member of
    no native: do not attemt to create a native implementation
    treat as object: treat as a object rather than a pointer
    The %info structure is initialized as follows:
    our %info =
    (
     root => { 
       options => [],
       groups => ['methods', 'group']},
     methods => {
       # methods is a collection of methods which will be inserted into
       # a class after some simple substation rules.  A $ will be
       # replaced with name of the class.
       options => ['strip', 'prefix', 'c impl headers'],
       groups => undef},
     group => {
       # a group is a colection of objects which should be grouped together
       # this generally means they will be in the same source file
       options => ['no native'],
       groups => ['enum', 'struct', 'union', 'func', 'class', 'errors']},
     enum => {
       # basic C enum
       options => ['desc', 'prefix'],
       creates_type => 'enum'},
     struct => {
       # basic c struct
       options => ['desc', 'treat as object'],
       groups => undef,
       creates_type => 'struct',},
     union => {
       # basic C union
       options => ['desc', 'treat as object'],
       groups => undef,
       creates_type => 'union'},
     class => {
       # C++ class
       options => ['c impl headers'],
       groups => undef,
       creates_type => 'class'},
     errors => {}, # possible errors
     method => {
       # A class method
       options => ['desc', 'posib err', 'c func', 'const',
                   'c only', 'c impl', 'cxx impl'],
       groups => undef},
     constructor => {
       # A class constructor
       options => ['returns alt type', 'c impl', 'desc'],
       groups => 'types'},
     destructor => {
       # A class destructor
       options => [],
       groups => undef},
     );
    In addition to the categories listed above a “methods” category by be
    specified in under the class category. A “methods” category is created
    for each methods group under the name “<methods name> methods”. When
    groups is undefined a type name may be specified in place of a category.
   %types
   
types contains a master list of all types. This includes basic types and ones created in mk-src.in. The basic types include:
    'void', 'bool', 'pointer', 'double',
    'string', 'encoded string', 'string obj',
    'char', 'unsigned char',
    'short', 'unsigned short',
    'int', 'unsigned int',
    'long', 'unsigned long'
  %methods
   %methods is used for holding the “methods” information
This module contains various useful utility functions:
falsetruecmap EXPR LISTone_of STR LISTto_upper STRto_lower STRto_mixed STRread
        Read in mk-src.in and return a data structure which has the
        following format:
      <tree>
      <tree> := <options>
                data => <tree>
    where each tree represents an entry in mk-src.in.  
    The following two options are always provided:
      name: the name of the entry
      type: the catagory or type name
    Additional options are the same as specified in %info
create_cc_file PARMS               Required Parms: type, dir, name, data
               Boolean Parms:  header, cxx
               Optional Parms: namespace (required if cxx), pre_ext,
                               accum
     
     create_file FILENAME DATA               Automatically generated file.
     
     is present in the existing file if it already exists.
The code generation modes are currently one of the following:
          cc:     Mode used to create types suitable for C interface
          cc_cxx: Like cc but typenames don't have a leading Aspell prefix
          cxx:    Mode used to create types suitable for CXX interface
          native: Mode in which types are suitable for the internal
                  implementation
          native_no_err: Like Native but with out PosibErr return types
   Helper functions used by interface generation code:
         to_c_return_type ITEM
             .
     
         c_error_cond ITEM
             .
     make_func NAME @TYPES PARMS ; %ACCUMParms can be any of:
                    mode: code generation mode
     
     call_func NAME @TYPES PARMS ; %ACCUMParms can be any of:
                    mode: code generation mode
     
     to_type_name ITEM PARMS ; %ACCUMParms can be any of:
               mode: code generation mode
               use_type: include the actual type
               use_name: include the name on the type
               pos: either "return" or "other"
     
     make_desc DESC ; LEVELmake_c_method CLASS ITEM PARMS ; %ACCUMParms is any of:
               mode:      code generation mode
               no_aspell: if true do not include aspell in the name
               this_name: name for the parameter representing the
                          current object
     
     call_c_method CLASS ITEM PARMS ; %ACCUMform_c_method CLASS ITEM PARMS ; %ACCUM               ($func, $data, $parms, $accum)
     
     which is suitable for passing into make_func. It will return an
        empty array if it can not make a method from ITEM.
     
make_cxx_method ITEM PARMS ; %ACCUMParms is one of:
               mode: code generation mode