Rewriting Camlorn_audio with libclang

Source

Quick update on Camlorn_audio: it's being rewritten.

here's why:

  • The current code works, but features are missing. This is because everything must be hand-typed, changes must be made across the entire codebase, and the OpenAL spec must be frequently consulted.

  • The current code works, but has bugs. Most of these are related to openAL error handling, and a few to threads.

  • Features that need to be implemented can't be implemented without rewriting streaming, which is the only nontrivial code in the entire thing.

In about 3 hours this morning, I succeeded in writing a 50-line script that turns all OpenAL macros into JSON. In about 6 hours this weekend, or when I get the time, I can probably follow it with a hundred-line script that does the same for all OpenAL functions.

A few things fall directly and indirectly out of such metadata:

  • All low-level classes for anything, now and possibly in future, can be trivially generated. This is easily 4 or 5 hundred lines.

  • All low-level classes can trivially have their functionality changed, i.e. error checking improvements, better threading, caching/recording for cloning, serialization...etc...

  • The bindings for Python can be auto-generated. So too can the bindings for your favorite language, whatever that may be.

  • Properties can be set by name, i.e. from a string.

  • You can query the metadata directly, getting lists of OpenAL properties and their ranges/possible values.

  • By folding the documentation into the metadata (human-generated, unfortunately), documentation can be released in the native format of the binding's language. Furthermore, for languages that do not support run-time documentation queries, functions can be provided that return the documentation.

  • Tables of all OpenAL parameters and functions, as well as those of camlorn_audio itself, can be generated automatically.

The strategy for this is Jinja templates, JSON, Libclang, and a strange combinational approach between data and C++ code. That is, for manually generated things, I will interleave C++ and--probably--YML. The metadata will generate error checking, allowing documentation on it without intervention (again).

And yes, this is basically a compiler, minus the compiling. The compiling used to be the hard part, anyway. So far I've got macros. Macros and plans.