Improving code generation

[ChrisDill]

I have tried a few different ways to generate binding code to make sure the bindings can stay up to date with the original. This post will be updated on the current state of the issue to hopefully make things clearer.

What has been tried so far?

CppSharp generator

• Close to what I wanted but a few issues with the output not being minimal and readable compared to what I had manually made.

Roslyn generator

• Contributed by @msmshazan, it is the generator currently included. I did find Roslyn a bit verbose and hard to add features to. Need to look into it more.

CppAST generator

• I saw this library that helps with the parsing and gave it a try. It works quite well and got me the most of the way. I had a few issues getting comments to align the way I wanted but it looks promising.

Custom raylib tool

• Inspired by other raylib tools and the parser from raylib-lua. I saw [this post](https://ourmachinery.com/post/creating-cross-language-apis/ and I got a basic idl format to parse.

[drwharris]

Hey Chris. Interestingly I have been working on some stuff with Roslyn and decided to spend a day working on trying to get the Raylib headers parsed and into CS files.

Not sure what you are doing to generate your pastebin sample but this would be 100% hands off.

My issue at the moment is that my C knowledge is not great so I am guessing at reasoning for certain decisions.

I have Enums done and Structs 95% done, just got to deal with array sizing. Here is the output so far using raylib.h https://pastebin.com/6dAk1tW7

Ive run out of free time this week, let me know if you think this is something you can use.

[ChrisDill]

There have been a few different attempts for code generation. The current generator which also uses Roslyn has not been used in a while so it is likely out of date.

One of the issues is handling has been handling edge cases for making the api easier to use. I am currently trying a approach based on this post.

I am interested to learn more about how you are generating that code.

[drwharris]

Sorry for delayed response. I am not doing anything particularly genius, just parsing the .h files and using Roslyn to build up a .cs file. Not really sure what the "approach" is you're talking about. What I got from that post was that the raylib library would have to have a very standardised API.

One thing I have noticed however is that you are incorrectly defining pointers as Object arrays. 2 Examples:

        [DllImport(nativeLibName, CallingConvention = CallingConvention.Cdecl)]
        //public static extern CharInfo[] LoadFontData(string fileName, int fontSize, int[] fontChars, int charsCount, int type);

        // Should be
        public static extern IntPtr LoadFontData(string fileName, int fontSize, int[] fontChars, int charsCount, int type);

        // Generate image font atlas using chars info
        [DllImport(nativeLibName, CallingConvention = CallingConvention.Cdecl)]
        //public static extern Image GenImageFontAtlas(CharInfo[] chars, int charsCount, int fontSize, int padding, int packMethod);

        // Should be
        public static extern Image GenImageFontAtlas(IntPtr chars, int charsCount, int fontSize, int padding, int packMethod);

I noticed it when I was doing the parsing previously but put it down to my poor C knowledge, but today I went to use these functions and came across the runtime errors.

I noted in the example (https://github.com/ChrisDill/Raylib-cs/blob/master/Examples/text/text_font_sdf.cs), line 36 "// TODO: fix conversion". This fixes that need

[ChrisDill]

I found the interface definition language interesting as it could store extra details that would be harder to specify in a header file since my bindings have a few differences that needed to be hard coded in the generator in previous attempts.

I have not fully tested all functions and the examples need to be updated. I will try to review those functions next.

[dallinbeutler]

Have you already looked into CppSharp for doing this? Before I looked further into it I figured you might have already tried it.

[ChrisDill]

CppSharp helped but it is more focused on C++ and I had issues generating the C bindings I wanted with it.

[dresswithpockets]

CppSharp is designed for both full C and C++ support. It relies on LLVM-Clang's parsers - which have support for all major C and C++ standards. I actually have a test project here that successfully generates and uses a C# binding from the raylib headers, using CppSharp, here: https://github.com/phxvyper/raylib-cppsharp

This is a basic example with a few issues, but it generates compatible bindings quickly and consistently.

There are a few minor code changes required in order to get the raylib headers to generate properly. For most of the headers, you have to include raylib.h somewhere near the top so that they get a definition of Vector2 during generation. I also add explicit casts whenever a coercion from int to float occurs in raygui.h - which is 3 times as of posting this.

Additionally, CppSharp also fails to cast its generated Vector2.__Internal type into a pointer when passing it into an adjacent p/invoke function in some cases. This is an easy bandaid (just cast it), but I haven't found a fix for it in CppSharp. It may be a bug, but as far as generating Raylib bindings go, its very minimal.

[ChrisDill]

When learning about PInvoke I used https://github.com/flibitijibibo/SDL2-CS for reference. Thanks for sharing your test project. I think I had something similar at the start but I could not figure out how to change the output to exactly what I wanted. For example I wanted the option to not have structs wrapped in classes or any name mangling.

There was a old issue and a possible solution about it but I don't think it was added. I also made my own issue about it here. The fork suggested is many commits behind master and I couldn't figure out what it did differently.

If you can get the bindings to generate in a similar way to what I currently have do let me know. I am currently trying the idea of a raylib inspired tool that can be made to work for different languages and it is looking promising.