Add support for a simple binding DSL

[anderslanglands]

The binding files are currently written in C++ in order to be able to take advantage of clang for parsing and constructing the AST. In order to get at the information we need, this means that the binding file structure is quite subtle and easy to get wrong as we're making use of a number of unrelated features (regular definitions, type aliases, annotation attributes, explicit template instantiaion) to tie the declarations in the binding to the corresponding declarations in the source library.

For instance, in order to properly declare a template method on a template class, one has to do this little dance:

namespace cppmm_bind {

template <class T> class Vec3 {
public:
    template <class S> void setValue(S a, S b, S c);
} CPPMM_VALUETYPE;

// explicitly instantiate the class template
template class Vec3<float>;
// note the 'extern' here otherwise we get an error because we're not
// defining the template body up above
extern template void Vec3<float>::setValue(float a, float b, float c);

} // namespace cppmm_bind

// and now we do the same for the source library - very confusing
template class Imath::Vec3<float>;
extern template void Imath::Vec3<float>::setValue(float a, float b, float c);

This is needless to say very error prone. I wrote the AST generator and I myself have to refer back to the example bindings to remember how to do it correctly

One thing we could do to improve this is to make a simple binding language that could be transpiled into the C++ that we feed to astgen on the fly (this would be done in-memory and provided to clang as virtual files).

My first idea about what that might look like is something like this:

#include <OpenEXR/ImathVec.h> 

namespace Imath = IMATH_INTERNAL_NAMESPACE;

template<T> 
class Vec3 
    binds Imath::Vec3<T>
    as valuetype
    for V3f = Imath::Vec3<float>; V3i = Imath::Vec3<int>; {{
        Imath::Vec3<T> normalized() const;
        template<S> void setValue(S a, S b, S c);
    }}

[luke-titley]

My first thoughts is that writing a language parser seems like a lot of work and could detract from the siggraph deadline we've given ourselves. Could this be done as a c++ api/library instead ?

[anderslanglands]

Well I think calling it a language parser is overselling it. I'm trying to design it such that it just parses out a few keyword/identifier tuples then copy/pastes the rest straight into the resulting c++ file.

In any case this is for further down the line anyway.

[luke-titley]

Oh ok, I get it. It's a great idea. It looks much more maintainable.