Re: C Binding Generation: Request for Comments

[Ori Bernstein <ori@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