There is little to mention about the elementary package files. As stated, these must include some code_for_xxx functions. Beyond that, a couple of extra functions may be provided, names init_handler and exit_handler. As their name suggest, these are called before and after the actual code generation. None of the built-in elementary package files un MPFQ makes use of the exit_handler mechanism, but the init_handler functions are widely used. These are meant to instruct MPFQ to add for example some #include statements in the generated code. The data fed to init_handler on input, and expected from its returned value, is specified as follows.
On input, a reference to a hash is provided. This exactly matches the $options argument which is fed to the create_code method from the main generator file. The init_handler may examine this hash, and base its returned value on that.
The output is also a reference to a hash. The members end up in the final $code hash in the generation mechanism (see main generator file). The expected members may be any of the following.
types. This defines the types provided by the implementation. For example, one may have:
sub init_handler {
return { types => { elt => "typedef unsigned long @!elt\[1\];" } };
}
banner. This gets inserted verbatim in the generated .c and .h files. For example one may have:
sub init_handler {
my $opt = shift;
return { banner => "/* $opt->{'poly'} */" };
}
includes. This defines files to be #include'd from the generated .h file. As an alternate syntax, the key c:includes may be used for files which are to be included only from the generated .c file. We may have:
sub init_handler {
return { includes => "<stdio.h>", 'c:includes' => "<inttypes.h>" };
}