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 > 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 .
>> 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.
