[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Interface generation
- From: Ruan Kendall <shearwater@...>
- Date: Tue, 27 Jul 2010 08:47:50 +0100
We run an application which supports a number of runtime-loadable code
modules in the form of .so files. One of these modules is a lua
interpreter. We currently provide lua bindings using a perl script
that generates a .h file from a text file of simple function
definitions. Each generated function wraps a function that is defined
in the main application, and these wrappers are compiled into the lua
Some of the modules provide general functionality... for example, one
code moules provides a spellchecker interface. In order for a lua
script to access this functionality, we must currently:
- Define the function in the code module
- Pass a pointer to that function back to a global variable in the
main application when the module is loaded
- Defined a wrapper which calls the function in the global variable
- Rebuild the world
When the module is loaded, the global variable reference is set. When
it is unloaded, it is cleared. The wrapper must check to see if it can
see the global variable is set to a non-null value, and throw an error
if it is not.
This means one bit of functionality must appear in three very
different parts of the code, which isn't really very nice and modular.
Does anyone have any suggestions on how this might be done better?
Approaches like SWIG seem to create .so files for libraries intended
solely for lua... the .so files we're using here are linked with the
application already and provide functionality which is used by the
program independantly of the scripting module.
- Lua will remain a module and will not be built into the core application.
- Function wrapper definitions should be as concise as possible
(currently a single line definition in our text file generates 15+
lines of C++ which handles argument checking, debug trace logging and
return value marshalling)
- Ideally, no lua-specific code (eg types or functions defined in the
Lua API) should reside in the code modules so we don't have to do vast
amounts of editting if the lua API changes or we decided to move to a
different scripting language (though that does seem rather unlikely at
- Both loading and *unloading* of functions is desired.
Thanks in advance!