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!
