From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Re: Binding generator, for Guile, to C libraries Date: Thu, 6 Jul 2017 21:57:28 +0200 Message-ID: <20170706215728.34f1806e@scratchpost.org> References: <20170627221608.A23B52013B@smtp.hushmail.com> <20170628154943.36021286@scratchpost.org> <20170629132246.9E3F92013A@smtp.hushmail.com> <20170703013035.47d47177@scratchpost.org> <8737aasg7z.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:32886) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dTCu9-0003q2-Os for guix-devel@gnu.org; Thu, 06 Jul 2017 15:57:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dTCu5-0003o9-6m for guix-devel@gnu.org; Thu, 06 Jul 2017 15:57:37 -0400 In-Reply-To: <8737aasg7z.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?ISO-8859-1?Q?Court=E8s?= Cc: guix-devel@gnu.org Hi Ludo, On Wed, 05 Jul 2017 23:53:36 +0200 ludo@gnu.org (Ludovic Court=C3=A8s) wrote: > Danny Milosavljevic skribis: >=20 > > Okay, I've cleaned up what I have and put it on github, under: > > > > https://github.com/daym/guile-gcc-unit > > > > What this does is it allows you to read gcc output files which specify = all the prototypes - in our case in order to extract the prototypes and gen= erate Guile bindings (of parted, or whatever). > > > > The next steps: > > - Provide the actual binding generator (I started a version of it - I'l= l commit a cleaned-up version in a few days I guess). > > - Get it to work with non-toy examples (see file "tests/huge/input" for= the parted non-toy example - the goal is to read this file, find all the r= ecord decls and all the function decls in it This part is working now, also for parted. > and generate the Guile pendants of them). If you happen to know LALR par= sing theory, I have a question :) > > - Find out whether that can be integrated as a Guile "language". Just = being able to do something like ',load "foo.h"' and have it register all th= e functions from it would be way cool. On the other hand, on non-Guix syst= ems the header files aren't usually installed when the library is installed= . So maybe an offline version would be good as well. =20 >=20 > Matt Wette, the author of nyacc, was apparently in the process of > writing a similar tool using nyacc=E2=80=99s C99 parser. Might be worth = looking > at. Nice! I've actually thought about using nyacc and mes for that - but since= we use gcc to compile everything, we can also use gcc to find out what it = compiled - it's more probable that that actually matches up. What I like i= s that gcc actually dumps the declarations even when you *don't* call the f= unction. So you can actually create a mostly-empty source file with #inclu= de in it and gcc will give you everything that is in scope. But it's definitely worth taking a look at Matt Wette's actual Guile dynami= c-* generator, maybe that can be shared between the projects. > Besides and FWIW, I=E2=80=99m skeptical of binding generators. Things li= ke > SWIG, for instance, generate interfaces that are often not quite what > you=E2=80=99d like, so you end up writing a layer on top of the generated= glue > anyway, not to mention annotation in headers.=20 Yeah, probably the bindings will suck a bit. But one can always write a wr= apper and not export all the original functions from there. Rust for examp= le has a "...-sys" convention where the package "foo-sys" contains the easi= ly-generated bindings and the package "foo" contains the actually simple hi= gh-level bindings. What I don't want is to manually maintain all the bindings. It's a compute= r, it should automate it :P Writing "override" declarations (or maybe even just literally overwriting t= he definition in Scheme) once every few months I'm fine with. Adapting the= bindings every time upstream adds a function? No. If I plan to use something like the "...-sys" convention in Guile, can I so= mehow re-export all the same names as the "-sys" package did, in a non-sys = package? For example: (define-module (foo-sys) #:export (a b c)) ... ------ (define-module (foo) #:re-export (same-names-as-in foo-sys, but use newer versions from below = if applicable)) (define (b ...) fix it up) ----- Hmm, I guess I can use (include-from-path "foo-sys") in the second module b= efore I overwrite anything. > (Bindings generated from > high-level descriptions like GIR and XCB are a different story; those > seem to work quite well.) Yeah, I like glib's approach with the def files which specify also the obje= ct lifetimes etc.