[ANN] Cgogen - automatic Go bindings generator released

[Maxim Kupriianov]

Hello everyone, 

today I'm glad to announce that after 3 months of full-time development back in 2015 and after 1 year of part-time field testing and improvements in 2016,

an automatic CGo bindings generator for Golang is finally released to the public. Visit https://cgogen.com

Sources: http://github.com/xlab/cgogen

Documentation: https://github.com/xlab/cgogen/wiki

That is the same generator that brought us Go bindings for Android NDK, Vulkan Graphics API, CMU PocketSphinx, ALAC and Ogg/Vorbis decoders, Pure Data embeddable library, PortAudio and PortMIDI adapters. And bindings for the libpvpx from WebM are on their way.

I hope the project will be useful for the community and awaiting for the feedback and issues.

Good luck y all!

--

Max

[Markus Zimmermann]

This looks pretty neat. We did something similar for https://github.com/go-clang/ The generator is here https://github.com/go-clang/gen and a resulting binding is here https://github.com/go-clang/v3.7 Maybe we can find some inspiration from each others projects? It would be also interesting to figure out how we could merge each efforts?

Cheers,
Markus

[Maxim Kupriianov]

Hi Markus, nice project! I must agree that the subject-specific bindings will always be superior over the generic ones. Another good example of that is https://github.com/therecipe/qt bindings with custom generator as well.

As for LLVM, I'm trying to avoid using it for now, because that's a very heavy dependency to have. Also that'd require rewriting more than half of the current code. One day we may join our efforts working on a generic C code transcriber, but that's another story.

> Maybe we can find some inspiration from each others projects?

I find the "ArrayNameFromLength" function curious, sadly things like that are almost impossible in a generic context, even with YAML hints.

Take a look onto my helper pipeline (gen_bindings.go), I used that approach instead of using templates that are pure evil for generating code.

I definitely will study your code deeply because it's interesting indeed to compare our approaches to the same problems.

Feel free to reach me out :)

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/3I7TzmEirbo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Markus Zimmermann]

On Tuesday, September 20, 2016 at 1:05:39 PM UTC+2, Maxim Kupriianov wrote:

Hi Markus, nice project! I must agree that the subject-specific bindings will always be superior over the generic ones. Another good example of that is https://github.com/therecipe/qt bindings with custom generator as well.

We tried to keep a lot of code generic so that we could make something like cgogen later on. You beat us to it :-) I would have loved to use something like cgogen but could not find anything related at that time.

Wow, github.com/therecipe/qt is huge.

As for LLVM, I'm trying to avoid using it for now, because that's a very heavy dependency to have. Also that'd require rewriting more than half of the current code. One day we may join our efforts working on a generic C code transcriber, but that's another story.

The dependency is not that big, it is just libclang and some other libraries however it is not as portable as having a C parser written in Go. A rewrite at this point would not make sense for either projects. Honestly, if something like github.com/cznic/cc had existed when I started working with go-clang I would not have started the whole rewrite. Are you a maintainer of github.com/cznic/cc ? What is your opinion of the maturity of the project?

> Maybe we can find some inspiration from each others projects?

I find the "ArrayNameFromLength" function curious, sadly things like that are almost impossible in a generic context, even with YAML hints.

I think that something like "ArrayNameFromLength" should be seen as a "first automatic draft" for a binding. If the user sees that something is not generated as expected, the user should be able to overwrite the generators heuristics. That is what we did with go-clang/gen. However, I agree with your concern. Such heuristics suck, but I think they are better than having none.

Take a look onto my helper pipeline (gen_bindings.go), I used that approach instead of using templates that are pure evil for generating code.

We used go/ast to generate most Go code which is complicated to use. However, I am pretty happy with the result and after some refactoring the whole generation would look rather easy. I did that for an internal project (I hope that I can open source parts of it) and this generic approach makes it easy to maintain generators for more than one language.

I definitely will study your code deeply because it's interesting indeed to compare our approaches to the same problems.

Feel free to reach me out :)

Looking forward to your changes :-) Contact me if you need any ideas/opinions.

I mentioned some concerns about cgogen here https://github.com/go-clang/design/issues/9 if you are interested. I can also over my help in setting up TravisCI and Coveralls, and making the whole repository more "go-ish".

On Tue, Sep 20, 2016 at 1:23 PM, Markus Zimmermann <zim...@gmail.com> wrote:

This looks pretty neat. We did something similar for https://github.com/go-clang/ The generator is here https://github.com/go-clang/gen and a resulting binding is here https://github.com/go-clang/v3.7 Maybe we can find some inspiration from each others projects? It would be also interesting to figure out how we could merge each efforts?

Cheers,
Markus

On Tuesday, September 20, 2016 at 10:19:14 AM UTC+2, Maxim Kupriianov wrote:

Hello everyone, 

today I'm glad to announce that after 3 months of full-time development back in 2015 and after 1 year of part-time field testing and improvements in 2016,

an automatic CGo bindings generator for Golang is finally released to the public. Visit https://cgogen.com

Sources: http://github.com/xlab/cgogen

Documentation: https://github.com/xlab/cgogen/wiki

That is the same generator that brought us Go bindings for Android NDK, Vulkan Graphics API, CMU PocketSphinx, ALAC and Ogg/Vorbis decoders, Pure Data embeddable library, PortAudio and PortMIDI adapters. And bindings for the libpvpx from WebM are on their way.

I hope the project will be useful for the community and awaiting for the feedback and issues.

Good luck y all!

--

Max

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/3I7TzmEirbo/unsubscribe.

To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.