On Saturday, 12 March 2022 at 09:55:03 UTC, Ki Rill wrote:

#include "raylib.h"

void main() {
    import raylib;

    InitWindow(640, 640, "ImportC raylib test");
    // game loop
    CloseWindow();
}

gcc -E raylib.c > raylib.i
dmd main.d raylib.c -L=-lraylib
./main

The big problem is that #define are missing. So a lot of const must be redefined or made explicit like:

ray.h:

#include "raylib.h"
Color RAYLIB_BLACK = BLACK;

But it's not so comfortable to use.

I would like to mix different languages, just like kotlin+java on android development or like calypso did.

On 3/14/22 6:47 AM, Andrea Fontana wrote:

#include "raylib.h"

void main() {
    import raylib;

    InitWindow(640, 640, "ImportC raylib test");
    // game loop
    CloseWindow();
}

gcc -E raylib.c > raylib.i
dmd main.d raylib.c -L=-lraylib
./main

#include "raylib.h"
Color RAYLIB_BLACK = BLACK;
  ```

But  it's not so comfortable to use.

I would like to mix different languages, just like kotlin+java on android development or like calypso did.

Yes, C does not allow manifest constants of anything other than integers via enum. Raylib has eschewed most (all?) #defines of integers, preferring enums, but e.g. a Color struct cannot be an enum.

The pain of having to not only redeclare manifest constants but also give them a different name is pretty high.

-Steve

On Monday, 14 March 2022 at 13:30:44 UTC, Steven Schveighoffer wrote:

I can't belive compiler can't handle a simple optimization for a non-manifest color const.

Is really a performance penalty to declare BLACK like this?

const struct Color BLACK = (Color){0,0,0,255

On 3/14/22 12:26 PM, Andrea Fontana wrote:

const struct Color BLACK = (Color){0,0,0,255

You can submit your request to raylib, and see if they accept it. I doubt it.

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.

-Steve

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

Would there be any benefit to having raylib-d take advantage of importC, rather than the user, but also keep around some of the things that make it easier to use, like the Colors enum?

On 3/14/22 2:02 PM, jmh530 wrote:

ImportC could replace much of the binding, sure. However, we have an additional problem in that raylib-d adds things to structs, such as operator overloads. That's not so easy to do.

ImportC itself is great for things that you want to "just use". Again, though, it needs to provide some mechanism to access #define constants and macros.

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.

Raylib itself is such a simple and well-organized library that I've contemplated just rewriting it in D with a D-like interface (use strings, use overloading, operator overloads, etc). But contemplation is all I have time for unfortunately :(

-Steve