Codegeneration

An upcoming release of XBMC will change the python interface from the existing hand coded one, with one whose code is generated as part of building XBMC. There are several advantages to this approach including:

1. More flexible and straightforward means of managing the API. The API will be defined in terms of a C++ library independent of the fact that it can be called from a scripting language.
2. Provide a means of merging different APIs into a single API accessed through different means. It would be nice to define the API independent of the means of access.
3. Tackle some longstanding stability issues resulting from the mixing of Python mechanisms with XBMC mechanisms. These are typically deadlocks.
4. Smaller source codebase to manage
5. Provide a basis to support other scripting language.

There are some distinct disadvantages.

1. Object code size will be larger.
2. As with any large and new module, there will be issues that need to be worked out.

How it works

In general, the code-generator is build in two phases. In the first phase SWIG is used to parse C++ header files that define the API. SWIG outputs an XML file that contains a complete description of the structure of the API. In the second phase, the XML file is ingested by a Groovy program that then creates C++ code that forms the bridge to the scripting language (Python).

Referring to the figure above, the following steps contain a little more detail.

1. A SWIG interface file is created per API module. The SWIG interface file is documented in the SWIG documentation. It is mainly a SWIG configuration file that includes each of the header files that is meant to be included in the given module. It is also used to insert code snippets into the generated code so that, for example, the appropriate dependencies can be '#include'-ed.
2. SWIG is run (currently from the Makefile) and XML is output for the given module. The XML file contains a full description of all of the code included via the SWIG interface file.
3. The XML file is ingested by a Groovy program in order to generate the final .cpp. Groovy has native XML parsing support as well as a built in template processor that makes it very powerful and flexible. When invoking the Groovy program, a template is supplied. The template drives the code-generation for a particular scripting language. It's basically the rule set for how to construct the language interface from the structured, parsed, API representation in the XML. The result is a C++ file that contains the scripting language interface code.
4. Finally the resulting C++ file is compiled into XBMC.