From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=3.0 tests=BAYES_40,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.5-pre1
X-Received: by 2002:a0c:eb10:: with SMTP id j16mr249798qvp.35.1603320506417;
        Wed, 21 Oct 2020 15:48:26 -0700 (PDT)
X-Received: by 2002:a05:620a:5e1:: with SMTP id z1mr5504096qkg.464.1603320506236;
 Wed, 21 Oct 2020 15:48:26 -0700 (PDT)
Path: eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Wed, 21 Oct 2020 15:48:25 -0700 (PDT)
In-Reply-To: <Z9ZjH.244265$ZL3.217123@fx33.am4>
Complaints-To: groups-abuse@google.com
Injection-Info: google-groups.googlegroups.com; posting-host=99.10.228.144; posting-account=AgomvAoAAAAj6rtZlNDUf1S1XVXbXDpg
NNTP-Posting-Host: 99.10.228.144
References: <9d822023-b604-46b1-9443-4471e095704bn@googlegroups.com>
 <mt1jH.117192$pc2.66953@fx03.am4> <491080f5-437a-465c-be5b-9aafdfc43b30n@googlegroups.com>
 <Z9ZjH.244265$ZL3.217123@fx33.am4>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <da4d1752-3833-46df-bade-93e094395705n@googlegroups.com>
Subject: Re: GDNative thick binding design
From: Michael Hardeman <mhardeman25@gmail.com>
Injection-Date: Wed, 21 Oct 2020 22:48:26 +0000
Content-Type: text/plain; charset="UTF-8"
Xref: reader02.eternal-september.org comp.lang.ada:60464
List-Id: <comp.lang.ada>

On Wednesday, October 21, 2020 at 12:17:00 PM UTC-4, persan....@gmail.com wrote:
> Michael 
> The "clone" is just an instantiation of the Binding template in the from 
> the same github-project. The important thing is the total structure that 
> is forcing hiding of the generated C-binding and it also makes it 
> trivial to regenerate the low-level stuff when the header-files changes 
> whats in the pipe as well is to semiautomatic generate the exported 
> interfaces and implementations, but the initial attempts are to crude to 
> put in the public they are just hacks so far. 
> 
> I am happy to to contribute but since the original project in my opinion 
> needed to much rework to start a discussion. I just instantiated my 
> template for C-bindings, and completed the .c and .sed files. 
> 
> And please see my project as an input with ideas on how I do believe 
> bindings to larger C/C++ libraries shall be done and not as a new clone 
> since i don't intend to do anything more with it that provide a 
> structure for a binding project. 
> 
> /Regards 
> /P
> On 21/10/2020 05:34, Michael Hardeman wrote: 
> > why create a clone of my project idea with generated bindings instead of just contributing to the working one I've already made? 
> >

I initially generated bindings to the headers, but they ended up needing significant work to be usable. I don't think automated generation of the binding is practical.
Since your program ends up being a dynamic library with 3 functions, and 1 of them is passed a pointer to the whole godot api as a single struct I don't think having multiple files is actually useful. It's a tricky API to use, and to bind to.