ImportC rocks! (page 3)

On 3/14/22 2:11 PM, Steven Schveighoffer wrote:

But as a D developer, using an actual C library gets quite annoying. You deal with it because it's what's available. But if I can add niceties to it, I'd rather do that.

One possible usage of ImportC which I just thought of, would be to statically verify the raylib binding you have is compatible with the raylib source.

So you build against raylib, including the .h file, and then you introspect all the functions/types in your raylib-d binding and the raylib c header, and if there are any mismatches, you report those.

I would absolutely accept such a verification system as a PR to raylib-d! I did plant a seed in raylib that for the next released version, I can verify at runtime that you are bound to the correct version of the library -- that was accepted by Ray.

-Steve

On Monday, 14 March 2022 at 18:11:09 UTC, Steven Schveighoffer wrote: > raylib-d adds things to structs, such as operator overloads. That's not so easy to do. struct DStruct { CStruct c_version; alias c_version this; DStruct op... }

March 15, 2022

Re: ImportC rocks!

Posted by Steven Schveighoffer
in reply to Andrea Fontana

Permalink

Steven Schveighoffer

Posted in reply to Andrea Fontana

Permalink

On 3/15/22 5:42 AM, Andrea Fontana wrote:

On Monday, 14 March 2022 at 17:49:23 UTC, Steven Schveighoffer wrote:

One thing that is very obvious from a few of my PRs is that raylib is not interested in making changes specifically to be binding-friendly. I think you will probably find this from many C libraries -- their focus is their library, not yours. If ImportC cannot work with C libraries as they stand without "simple tweaks", then it's just not going to be worth much.

I see you're using dstep to generate bindings. Do you know there's a file with all the exports? Did you try to generate bindings from it?

https://github.com/raysan5/raylib/blob/master/parser/raylib_api.json

(json is not the only format available, check that folder).

I did not know that, thanks for pointing it out! I'm going to stick with DStep for a few reasons:

Raylib's home-grown raylib-only header parser is probably not as mature as clang.
There isn't an already existing mechanism to parse these json files and produce D code. I'd have to write it.
Any tool that I write is useful for raylib, and nothing else.
Releases on raylib happen so infrequently, that the 30 minutes it takes for me to run dstep and the subsequent fixup is not a burden.

If ImportC gets to the point where you can truly import C headers, then I might switch to something like that.

-Steve

On 3/15/2022 5:38 AM, Steven Schveighoffer wrote: > If ImportC gets to the point where you can truly import C headers, then I might switch to something like that. Please give it a try, and report any problems to Bugzilla!

On Friday, 18 March 2022 at 05:06:29 UTC, Walter Bright wrote: > On 3/15/2022 5:38 AM, Steven Schveighoffer wrote: >> If ImportC gets to the point where you can truly import C headers, then I might switch to something like that. > > Please give it a try, and report any problems to Bugzilla! Is there any documentation on how to use importC with dub? I have a project using wgpu-native bindings which I've been generating with Dstep. I'd love it if I could import C headers directly.

Forums