autogen C bindings

[Daniel Skinner]

I'm wondering if there's anything out there to autogenerate C bindings into a Go file for use with cgo. Specifically, this would be just like dumping the "C" of `import "C"` except for a specific header file.

The goal here is simply to get a starting point for creating more proper bindings, where as right now I'm just doing it by hand and scripted a little. As an example, I could dump GLES2/gl2.h into a gles2.go file which semantically would include all the defines as consts, and and functions with the same signatures under `import "C"` and calling `C.foo(*args)`.

I was thinking of using clang to parse the header and then generating go source but wondering if this problem is already solved somewhere. Hows does pkg "C" determine its contents? Can that be leveraged?

[Sebastien Binet]

Daniel,

well, there's swig "of course", which outputs something "reasonnably"
go-ish (although one has to add a hand-made layer to make the API
really look like proper Go)

otherwise, at some point I started something based on gccxml (with the
ability to add a clang plugin for the parsing as well)
it's unfinished and was mainly tailored at C++, but here you go:
https://github.com/sbinet/go-cxxdict

-s

[Daniel Skinner]

I'll have a look at what swig outputs, haven't used it with go before and it slipped my mind. Just having some boilerplate to work with would be a step forward.

go-cxxdict looks interesting and may be more what I'm after though as boilerplate would be the easy goal, but more would be nice. Another bit I wanted to do was autogenerate docs based on the original but reflect the binding. I could possibly hook into this for specifying how to determine docs and how to handle them based on such.

[Sebastien Binet]

On Thu, May 9, 2013 at 7:32 PM, Daniel Skinner <dan...@dasa.cc> wrote:
> I'll have a look at what swig outputs, haven't used it with go before and it
> slipped my mind. Just having some boilerplate to work with would be a step
> forward.
>
> go-cxxdict looks interesting and may be more what I'm after though as
> boilerplate would be the easy goal, but more would be nice. Another bit I
> wanted to do was autogenerate docs based on the original but reflect the
> binding. I could possibly hook into this for specifying how to determine
> docs and how to handle them based on such.

gccxml won't be able to do that, for sure, but clang should (and
already kind of does what doxygen is used to, see the cldoc
clang-based tool:
http://jessevdk.github.io/cldoc/)

as a first step, one could perhaps use <shameless plug> my clang bindings:
https://github.com/sbinet/go-clang
</shameless plug>

(but perhaps shelling out to cldoc might just be easier for taking
this off the ground)

-s

[Sebastien Binet]

On Thu, May 9, 2013 at 7:38 PM, Sebastien Binet <seb....@gmail.com> wrote:
> On Thu, May 9, 2013 at 7:32 PM, Daniel Skinner <dan...@dasa.cc> wrote:
>> I'll have a look at what swig outputs, haven't used it with go before and it
>> slipped my mind. Just having some boilerplate to work with would be a step
>> forward.

BTW, go-1.1 will have builtin and go-get-able support for swig (just
put the .i interface files in the repo and name them .swig for C
libraries and .swigcxx for C++ ones)

-s

[Daniel Skinner]

thanks, i actually have your clang bindings for another project. I remember now I saw the support for swig when I was applying a patch to tip for CPP compilation support as well, yet it still slipped my mind.

+1 for cldoc, looks nice and could be part of a modular solution to this