Community input for a new C binding generator project

[Rikki Cattermole]

On Wednesday, 2 April 2014 at 14:33:04 UTC, James Buren wrote:
> I have thought of designing a new C binding generator that 
> tries to do more than dstep currently does. At the very least 
> that would include automatic conversion of simple macros. Such 
> as: characters, strings, aliases, integers, constant integer 
> expressions, etc. Another thing I wish to add is mapping of 
> standard C types to their D types in core.stdc.* if it is 
> already defined there.
>
> However, while doing research for the project, I have come 
> across a number of concerns I have. So, I am asking for 
> community input before I get serious with this project because 
> I want to actually make something people would want to use.
>
> Specifically, this is what I need to know about:
>
> 1) C has many standards (C89/C99/C11) and non-standard 
> extensions (GNU C). By the very nature of C grammar, it can be 
> quite difficult to parse properly. Would anyone care if I 
> excluded non-standard features that may be present in a header? 
> For example, non-standard bitfields -- they use integers other 
> than 'int'. This is non-portable behavior.
>
> 2) As an extension to above, should I bother supporting rarely 
> used features? Some of them are non-standard but others are 
> standard. For example, #pragma pack() or GNU attributes and how 
> those effect struct alignment in the D interface module is 
> non-standard. Another example is converting inline functions, 
> which is supported via C99 standard.
>
> 3) Should I provide an interface for mapping preprocessor 
> macros which cannot be automatically converted by machine 
> logic? For example, function macros cannot be converted 
> automatically because you can't be sure what type of argument 
> is expected. Other macros may not be worth converting because 
> they are simply used for generating code.
>
> 4) As an extension to questions 1 and 2, is it worth it to you 
> for non-standard C features to be supported? This would likely 
> make generating a portable D interface more difficult as the D 
> interface is limited by what the platform's C compiler 
> supports. For example, if struct alignment is used but the 
> platform's C compiler does not support this non-standard 
> feature, then the D interface would have to exclude it from 
> this platform's version of the module.
>
> 5) Should I avoid reusing code from a GPLv2 / GPLv3 project? 
> I'm not sure if this makes anyone uncomfortable. Supposedly 
> most GPL program output retains the license of the input, but 
> I'm not totally convinced. I am not sure if the viral nature of 
> the GPL would make people unwilling to use my tool.
>
> 6) Anything else you would like to see in a C binding 
> generator? I may not implement it, but knowing what people want 
> would help me anyway.
>
> Thank you for reading this.

Interestingly I was having a play recently with a CTFE'd macro 
preprocessor in the hope that I could push it through a c lexer 
and create via template mixins the entire bindings to files.
Few limitations like string imports not recursive on Windows (one 
day I might look into that).
But netherless a lot of work, and fun!