1.1 Why Create a Wrapper Generator?

When accessing a given foreign API from a variety of target languages, the description of the foreign API is a common bit of information that will be needed by the infrastructure supporting each of the target languages. Further, since the internal mechanisms by which a given target language can access a foreign API are often in flux, it makes sense to consider automatically generating the "glue code" that binds the library API and the target language together. This means that whenever the foreign function access mechanisms in a target language change, only G-Wrap (or some similar tool) will need to be updated. Then all of the relevant glue code can be trivially re-generated. This is the job that G-Wrap was designed to handle.

In truth, one of the primary goals of G-Wrap is also to acumulate as many language independent definitions of various APIs as possible, so that interfaces for other languages may be generated automatically, whether by G-Wrap, or some other program.

The original motivation for G-Wrap came from Aubrey Jaffer’s suggestion to Christopher Lee that using Scheme to parse a language neutral API specification and generate glue code would be a good way to address this problem for Scheme interpreters. G-Wrap may well evolve beyond that to support other languages, but for now, it only handles access to C APIs from Guile.

In fact, the original implementation of G-Wrap was much more declarative than programmatic. The API specification files were not executable Scheme code, but rather declarative Scheme forms. In the long run, this might be preferable, if G-Wrap decides to move in the direction of language independence, or an alternate possibility is to design a language neutral API spec file (as guile-gnome is trying to do) and then just have a translator from that to native G-Wrap calls.