Modules are shared binaries. Their main purpose is to deliver tables of
functions and classes for object-oriented access to GUI elements and
multimedia data.
Building modules consists of two parts:
+ a macro to use in mmakefile.src files
+ a configuration file that describes the contents of the module.
The build system calls the tool "genmodule" in order to create some additional
C source and header files. This tool is driven be a configuration file which
allows to set a lot of options for the fine tuning of the generated files.
Configuration files contain named sections with definitions:
##begin <sectionname>
<definitions>
##end <sectionname>
Sectionname can be "config", "class", "cdefprivate", "cdef", "functionlist",
"methodlist" or "startup".
The lines in this section have all the same format:
optionname string
with the string starting from the first non-white-space after optionname
to the last non-white-space character on that line.
- basename
- Followed by the base name for this module. This will be used as a
prefix for a lot of symbols. By default the modname specified in the
makefile is taken with the first letter capitalized.
- libbase
- The name of the variable to put the library base in. By default the
basename will be taken with "Base" added to the end.
- libbasetype
- The type to use for the libbase for internal use by the library code.
E.g. the sizeof operator applied to this type has to yield the real
size of the object. Be aware that it may not be specified as a pointer.
By default 'struct Library' is taken.
- libbasetypeextern
- The type to use for the libbase for code using the library externally.
- version
- The version to compile into the module. This has to be specified as
<major>.<minor>. By default 0.0 will be used.
- date
- The date that this library was made. This has to have the format of
DD.MM.YYYY. As a default the current date is taken.
- copyright
- Example: copyright Copyright (C) 2006 Foobar team
- forcebase
- This will force the use of a certain base variable in the static
link library for auto opening the module. Thus it is only valid for
modules that support auto opening. This option can be present more than
once in the config section and all these base variables will be in the
link library. By default no base variable will be present in the link
library.
- superclass
- FIXME
- superclass_field
- FIXME
- residentpri
- FIXME
- options
Comma separated list of options.
- noautolib
- FIXME
- noexpunge
- FIXME
- noresident
- FIXME
- peropenerbase
- Every time the library is opened a new address is returned. This is
useful if you have defined libbasetypeextern.
- peridbase
- FIXME
- includes
- FIXME
- noincludes
- FIXME
- nostubs
- FIXME
- autoinit
- FIXME
- noautoinit
- FIXME
- sysbase_field
- FIXME
- seglist_field
- FIXME
- rootbase_field
- FIXME
- classptr_field
- FIXME
- classptr_var
- FIXME
- classid
- FIXME
- classdatatype
- FIXME
- beginio_func
- Name of the beginio function of a device.
- abortio_func
- Name of the abortio function of a device.
- dispatcher
- FIXME
- initpri
- Sets the priority of initialization if you have more than one class
in a conf file. Use this if you want to ensure that a base class
is initialized before a sub class. The class with the highest
value is initialized first.
- type
- FIXME
- getidfunc
- FIXME
You need "class" sections only when you want to define additional classes in
your module. If you create a module for e.g. a gadget a class for a gadget
is automatically created. This means you can use the definitions below
in the "config" section.
- type
Type of the class. Possible values:
- mcc
- See Module Types.
- mui
- See Module Types.
- mcp
- See Module Types.
- image
- BOOPSI image class.
- gadget
- See Module Types.
- datatype
- See Module Types.
- class
- FIXME
- hidd
- See Module Types.
- superclass
- Name of the parent class. Example: superclass MUIC_Group.
- superclass_field
- FIXME.
- classptr_field
- FIXME
- classptr_var
The variable which contains a pointer to the class is per default hidden.
If you need to have access to this pointer you have to use this option,
like:
classptr_var MyClass
- classid
Public name of the class, either a string or a C macros. Examples:
classid "gradientslider.gadget"
classid AROSCHECKBOXCLASS
- classdatatype
- Example: classdatatype struct Data.
- dispatcher
- Use this if you want to use a dispatcher which exists in
the source code instead of one generated by the build system.
In this section all the C code has to be written that will declare all the
type of the arguments of the function listed in the function. All valid C
code is possible including the use of #include.
Like "cdef" but for all declarations which must not be visible for the
module user.
In this section are all the functions that are externally accessible by
programs.
For stack-based argument passing, only a list of the functions has to be
given:
##begin functionlist
void func1(LONG a, LONG b)
int func2(char *s, ULONG a)
##end functionlist
For register-based argument passing, the names of the register have
to be given between parentheses:
##begin functionlist
ULONG func5(ULONG a, STRPTR b) (D0,A0)
##end functionlist
There are some tags which influence the previously defined function.
- .skip n
- Every function gets an index number, the Library Vector Offset.
With this tag you can increase the LVO without inserting empty
lines in the "functionlist" section.
- .alias name
- Define an alternate name for the function.
- .function name
- FIXME
- .cfunction
- FIXME
- .private
- FIXME
- .novararg
- FIXME
Here you can list all you methods for an automatic creation of a dispatcher.
The real function name for a method "name" must become <basename>__<name>
in the source code.
There are some tags which influence the previously defined method.
- .alias name
- Alternative name for the method
- .function name
- FIXME
- .interface name
- FIXME
