Re: C Binding Generation: Request for Comments
[Thread Prev] | [Thread Next]
- Subject: Re: C Binding Generation: Request for Comments
- From: Ori Bernstein <ori@xxxxxxxxxxxxxx>
- Date: Mon, 25 Jan 2016 00:46:42 -0800
- To: Ori Bernstein <ori@xxxxxxxxxxxxxx>
- Cc: myrddin-dev@xxxxxxxxxxxxxx
Oops, two important points I missed. - The package definitions for C code would be in their own .cbind files. - As far as actually doing type conversions for, eg, strings -- with the current iteration, you basically need to convert slices to C strings by hand. If anyone has thoughts on doing this (semi?)automatically, that might be nice. On Sun, 24 Jan 2016 23:59:00 -0800, Ori Bernstein <ori@xxxxxxxxxxxxxx> wrote: > So, I'm looking at improving mcbind and making it usable in general for > defining Myrddin modules. > > Current State > ------------- > > At the moment, it transitively includes *everything*. This means that if you > generated bindings for sqlite.h and for xcb/xcb.h, you would get common types > duplicated, leading to, for example, sqlite.size_t and xcb.size_t. > > Sketch of Proposal > ------------------ > > To solve this, I've been eying giving mcbind knowledge of modules and module > interdependencies. The way this would work: > > - First, we parse the module file, which contains a list > of files to include, and a list of modules that it depends > on. > > - For each module, we recursively load it, and read the declarations, > putting them into that module's namespace. > > - Then, we load each of the headers defined in the module, from > scratch. If we've already seen a declaration in a previous module, > it is discarded. > > - Finally, the code is emitted. Only the module that has been passed > directly is processed. Any recursively loaded modules are omitted. > > This also allows for recording which cflags and ldflags should be used, > in the module definition. > > Module Definitions > ------------------ > > Borrowing quite a few ideas from the C++ modules discussion, I'm thinking > that I might define something like this: > > pkg stdlibc = > header = "stdint.h" > header = "stdio.h" > header = "stddef.h" > ...etc... > ldflags = -lc > ;; > > pkg x11 = > use stdlibc > header = "X11/X.h" > header = "X11/Xproto.h" > ...etc... > ldflags = -lX11 > cflags = -Dwhatever > ;; > > This has at least two major problems: > > 1) Portability. system C headers are disgusting, confusing, and almost > as bad as the tools like autoconf that spawned to deal with them. > Required linker flags re different between platforms. There are > tons of different discovery systems. > > 2) Fragility. For example, if one of the dependencies is missing an > include, then symbols will be dumped into the wrong place. > > Comments, thoughts, insults? > > -- > Ori Bernstein > -- Ori Bernstein
C Binding Generation: Request for Comments | Ori Bernstein <ori@xxxxxxxxxxxxxx> |
- Prev by Date: C Binding Generation: Request for Comments
- Next by Date: Half Assed, Noisy Valgrind Support: Patch.
- Previous by thread: C Binding Generation: Request for Comments
- Next by thread: Half Assed, Noisy Valgrind Support: Patch.
- Index(es):