AROS Application Development Manual -- Modules
Modules are shared binaries. Their main purpose is to deliver tables of
functions and classes for object-oriented access to GUI elements and
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 has the macro "build_module" for the task of creating
modules. The parameters are:
- This is the name of the metatarget that will build the module. Also a
%(mmake)-quick and %(mmake)-clean metatarget will be defined.
- Name of the generated module without the suffix.
- Type of the generated module. Possible values: library, mcc, mui, mcp,
device, resource, gadget, datatype, hidd, usbclass, handler or hook.
- You don't normally need to specify this as the build system has a default
suffix for every type of module.
- A string which will be appended to the version string of the module.
- The name if the configuration file. Default is <modname>.conf.
- A list of all the C source files, without the .c suffixes, that make up
the code for this module. By default all the .c files in the current
directory will be used.
- A list of all the C++ source files, without the .c++ suffixes, that make up
the code for this module. By default all the .c++ files in the current
directory will be used.
- A list of all the C source files, without the .c suffixes, that contain
the code that needs to be added to the module linklib.
- A list of all the object files, without the .o suffixes, that contain
the code that needs to be added to the module linklib.
- The flags to use when compiling the .c files. By default the standard
AROS cflags (e.g. $(CFLAGS)) are taken. This also
means that some flags can be added by assigning these to the
USER_CFLAGS and USER_INCLUDES make variables before using this macro.
- The flags to add when doing the dependency check. Default is the same
as the cflags.
- The directory where to generate all the intermediate files. The
default value is $(OBJDIR) which in itself is by default equal to
- Target directory. See table "Defaults" below.
- A prefix for the path where the "Development" directory will be created
The generated headers and linklibs will be stored there.
The name to be used for the static link library that contains the
library autoinit code and the stubs converting C stack calling
convention to a call of the function from the library functable with
the appropriate calling mechanism. These stubs are normally not needed
when the AROS defines for module functions are not disabled.
There will always be a file generated with the name
$(LIBDIR)/lib%(linklibname).a and by default linklibname will be
the same as modname.
A list of static libraries to add when linking the module. This is the
name of the library without the lib prefix or the .a suffix and
without the -l prefix for the use in the flags for the C compiler.
By default no libraries are used when linking the module.
- Same as uselibs but for static libraries of the host system.
- The compiler for building the module. Can be "target", "host" or
"kernel". Defaults to "target" which creates binaries which run
- Defines whether the module should be linked with startup code. Defaults
- If "yes" the module will be created in an architecture specific
directory. Defaults to "no".
- Collection of functions.
- Driver for USB devices.
- MUI custom class.
- MUI standard class.
- MUI preferences class. This kind of Zune classes are shown in the Zune
- EXEC device driver.
- Lightweight libraries.
- Intuition GUI elements. These are also known as BOOPSI gadgets (Basic
Object-Oriented Programming System for Intuition).
- The datatypes system allows loading of all kind of data (graphics, music,
text etc.) into your application.
- A HIDD is a Hardware Independent Device Driver - a collection of code
that provides an interface to hardware that hides as many details of
the hardware as practical.
- DOS device driver.
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:
Sectionname can be "config", "cdef", "cdefprivate", "functionlist", "cfunctionlist",
"startup", "methodlist", "class", "handler", "interface" or "attributelist".
The lines in this section have all the same format:
with the string starting from the first non-white-space after optionname
to the last non-white-space character on that line.
- 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.
- The name of the variable to put the library base in. By default the
basename will be taken with "Base" added to the end.
- 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.
- The type to use for the libbase for code using the library externally.
- The version to compile into the module. This has to be specified as
<major>.<minor>. By default 0.0 will be used.
- 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.
- Example: copyright Copyright (C) 2006 Foobar team
- 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
- Name of the parent class. Example: superclass MUIC_Group.
Sets the value of the rt_Pri field in struct Resident. Additionally,
the resident flag is set:
Comma separated list of options. The defaults depend on the type of module.
- Do not call the symbolsets.
- Do not expunge the module.
- Do not create struct Resident.
- Every time the library is opened a new address is returned. This is
useful if you have defined libbasetypeextern.
- See comments in writestart.c of genmodule.
- Create the module's public include headers (proto, clib, defines, inline).
- Don't create public include headers.
- Don't write the stubs file for the linker library.
- Add code for automatic library opening to the linker library.
- Don't add code for automatic library opening to the linker library.
- Automatically setup the library functions in struct Resident.
- Do not add standard functions for opening and closing the module.
- Sets the name of the sysbase field in the library.
- Sets the name of the seglist field in the library.
- Sets the name of the rootbase field in the library.
- Sets the name of the classptr field in the library.
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,
Public name of the class, either a string or a C macros. Examples:
- Example: classdatatype struct Data.
- Name of the beginio function of a device.
- Name of the abortio function of a device.
- Use this if you want to use a dispatcher which exists in
the source code instead of one generated by the build system.
- 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.
- Set the type of a class.
"mcc", "mui", "mcp", "image", "gadget", "datatype", "usbclass", "class", "hidd"
- Define the variable name of struct Resident.
- Sets the name of the oopbase field in the library.
- See comments in genmodule's source.
- Sets the ID of the interface.
- Sets the name of the interface.
- Sets the name of the handler function.
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
In this section are all the functions that are externally accessible by
For stack-based argument passing, only a list of the functions has to be
void func1(LONG a, LONG b)
int func2(char *s, ULONG a)
For register-based argument passing, the names of the register have
to be given between parentheses:
ULONG func5(ULONG a, STRPTR b) (D0,A0)
There are some modifiers which influence the previously defined function.
- Define an alternate name for the function.
- Define the real name of the function in the source code. Note that
for register based function that name will be prefixed by basename
- Adds a wrapper from a register based function to a C fucntion.
Do not create a vararg wrapper for the function. By default that
wrapper is generated for register based functions if:
- The last letter of the function name is A; the vararg function name is
the name without this letter A.
- The function name ends in TagList; the vararg function name is TagList
replaced with Tags.
- The function name ends in Args and the name of the last argument to the
function is args or arglist or a variation with other capitalization
(Args, Arglist, ArgList, ...); the vararg function name is the name
without the ending Args.
- The type of the last argument is "struct TagItem *"; the vararg
function name is the name with Tags appended.
There are some modifiers which influence the following functions.
- 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.
- The function will be only available if the library is opened with
at least that version.
Same as functionlist but with modifier ".cfunction" for each function.
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.
- Alternative name for the method
- Define the real name of the function in the source code.
The content will be written at the begin of autoinit.c which will be part
of the autostart linker library.