Upgrade to 3.7.0 - Githubissues

ArthaTi commented 3 years ago

The bindings in the repo are outdated.

I did a bit of work in my fork https://github.com/Soaku/raylib-d/tree/upgrade-3.7.0 but that's just one file, plus I didn't move the rlgl part out, like it has been done in raylib. I might have also missed some changes from before 3.5.0 because I was looking at a diff between 3.5.0 and 3.7.0 and I've noticed there have been a couple of changes.

Because of how many changes there have been done, it might be worth regenerating the files with a binding generator instead, my work is prone to mistakes.

schveiguy commented 3 years ago

Just a note, I think we should diff between 3.0.0 and 3.7.0 because raylib-d has not been updated since 3.0.0 AFAIK.

ArthaTi commented 3 years ago

Should be much better now, all files have been upgraded to follow what was changed in Raylib (including breaking backward compatibility…).

I've moved some of the custom types such as Bivector2 to raymathext.d so they don't have to be moved back every time the headers are updated.

Some notes:

~~It might be worth to move the Colors enum to a separate file, dstep doesn't like it. Maybe the --alias-enum-members could help but I haven't looked into it.~~ Done.
I fixed inconsistency regarding spaces before parenthesis in raymath.d. No spaces now.
Some enum parameters in the existing bindings refer to actual enums, not int. I didn't correct this after regenerating the header, so the type information is lost.
I might have overlooked some local changes to raylib.d. It might be worth listing them in a separate file next time…
It definitely would be worth adding unittests for local changes to raylib.d…

ArthaTi commented 3 years ago

Passes all unittests and works with all my repos.

schveiguy commented 3 years ago

Don't have time at the moment to look. Does it have instructions on how it was created and what steps need to be taken to recreate? I definitely want that in there.

ArthaTi commented 3 years ago

Alright, will do. I think I'll also move all the modified types to a separate module (so basic Vector2 etc too) so later regeneration will only involve removing symbols in CLI.

Also, I didn't touch raygui. I'm interested if someone actually got it working in D, since it's header only, I didn't mess with it much.

ArthaTi commented 3 years ago

Added a generating.md file. Repeated the process described in it multiple times to make sure everything is in it, looks like I got it right.

schveiguy commented 3 years ago

Nice!

I wanted to respond to a comment you made, but then removed, and that is about adding @safe attributes. I am firmly against adding @safe to any extern(C) functions that are not written in D (and not marked @safe). Because @safe implies the compiler has checked the code, and this is simply not true for C-compiled functions. It might be reasonable to add @trusted to some functions, but I'm not sure that's appropriate anyway, since that means any changes to raylib need to be audited by us for memory issues.

schveiguy commented 3 years ago

Also, I didn't touch raygui. I'm interested if someone actually got it working in D, since it's header only, I didn't mess with it much.

This is problematic, but not a deal-breaker. As long as the header-only library works with current raylib, it should be OK (and IIUC, if you can build with tests, it should be correct). However, tracking 2 independent bindings here is kind of difficult. I would say, let's track raygui manually, and not with a binding generator. An all-header library is going to use more preprocessor features, and make things complicated. I would need someone who uses the raygui portion to help maintain that. It was only added to this binding 18 months ago, and seems to have only one commit.

schveiguy / raylib-d

Upgrade to 3.7.0 #3