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 > <javascript:>> 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 <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
