Beginning with release 0.6 for LinuxPPC, OpenMCL uses a set of GDBM database files which contain foreign type, record, constant, and function definitions derived from the Linux header files. An archive containing these database files (and a shell script that was used in their creation) is available:
This archive (like OpenMCL binary and source distributions) should be extracted in the parent directory of the CCL directory.
OpenMCL defines reader macros that consult these databases:
#$foo looks up the value of the constant definition of FOO
#_foo looks up the foreign function definition for FOO
In both cases, the symbol FOO is interned in the LINUX package. The #$ reader macro has the side-effect of defining FOO as a constant (as if via DEFCONSTANT); the #_ reader macro has the side effect of defining FOO as a macro which will expand into an (EXTERNAL-CALL form.)
In addition, references to foreign type, structure/union, and field names (when used in the RREF and RLET macros) will cause these database files to be consulted.
Since the OpenMCL sources now contain instances of these reader macros (and references to foreign record types and fields), it's now necessary to install the interface database before compiling OpenMCL.
GDBM is licensed under the GPL. This could have implications for applications developed with OpenMCL. However, it's worth noting that:
OpenMCL's use of GDBM typically happens at read-time and at compile-time; this isn't likely to be an issue for most applications.
The variable CCL::*USE-GDBM*
can be set to NIL in a saved application. OpenMCL will (not surprisingly) not use GDBM unless this variable is true.
GDBM provides appropriate functionality and works well, but it may be possible to use or develop an alternative.
Other issues:
Although the interface translation process preserves the case of external symbols, the identifiers used as database keys are mapped to uppercase. (This means that if there are distinct foreign symbols that differ only in case, only one of them will be accessible via the database.) Ultimately, this issue needs to be addressed; ideally, it'll be addressed in some way that doesn't force users to pay more attention to case issues than is necessary.)
The databases are derived from a somewhat arbitrary set of Linux header files. Linux is enough of a moving target that it may be difficult to define a standard, reference set of interfaces from which to derive a standard, reference set of database files.
For information about building the database files, see here.