cxgo
cxgo copied to clipboard
gotranspile
Add GLFW/glfw3.h and update opengl.h
I wouldn't merge it just yet. I wanted to make sure the header looked good before I wrote an adapter. I had a few questions:
- what to do about
glfwSetErrorCallback. There is no equivalent in the go-gl/glfw library. Should I just make a function that does nothing in the adapter library? - Also, I didn't know how to properly handle the callbacks. The set callbacks functions are methods on a window which is easy enough to implement. However, the callback function itself takes a pointer to the window. How would I define a callback type since the
windowTwasn't defined yet? - Once I finished the adapter library would it be cloned onto gotranspile account?
what to do about glfwSetErrorCallback. There is no equivalent in the go-gl/glfw library. Should I just make a function that does nothing in the adapter library?
Yes, looking at the name we can fake it for now.
Also, I didn't know how to properly handle the callbacks. The set callbacks functions are methods on a window which is easy enough to implement. However, the callback function itself takes a pointer to the window. How would I define a callback type since the windowT wasn't defined yet?
If I understand correctly you are asking how to define a pointer to a type, before defining the type, right?
If so, you can check how FILE is defined. The general idea is that you first create a pointer type with no underlying type (aka void*), then define a named type with all the callback which can potentially use the pointer type that you defined, and then set the underlying type of the pointer to the named type you just created.
Once I finished the adapter library would it be cloned onto gotranspile account?
Yes, if it's okay for you. It would be easier to move it to the same org. I should also invite you to the organization, by the way.
@dennwc sorry I haven’t been working on this. I have been busy with uni. I’m not sure when I’ll have time again to work on the commit. It is just missing some callbacks and methods but overall it is correct. If you want to just merge this in you can or wait until I have time to add the rest. Also the gotranspile/glfw is 100% done as long as there are no future functions that need specific changes. I don’t know any off the top of my head.
Hello, I was wondering if the end-goal of this work is to transpile glfw to pure go ? I've seen this adapter https://github.com/gotranspile/glfw, but I don't understand its use, is it a first step toward it ? edit: Also I probably should have created an issue there ? (Sorry)
Hey @Zyko0 ! Cxgo could be used to eventually transpile GLFW to pure Go, but that's not the main goal. This specific PR make it easier to transpile C projects that use GLFW to Go. Having said that, it would be interesting to try what you proposed.
Thank you for clarifying ! Yes we might need to port glfw to Go for https://github.com/hajimehoshi/ebiten project anyway, so I wanted to know if this work started somewhere else 😅
@Zyko0 I've actually really wanted to port glfw to pure go. The main issue is that it would require porting the windowing apis for windows and linux. There are many pure go windows api libraries but none are complete so someone would need to use the metadata to generate it (see this issue). For linux, there is an XCB port but glfw uses XLib and wayland so those would need to be ported. Then headers will also need to be written which would be a lot of work. Either way, glfw on mac would still require c because there is no way to create a window without ObjC. It's a noble effort that I hope eventually gets done!
@TotallyGamerJet Thanks for your explanations about the current state of such a port ! 😄
This is open for quite a while now, so I'll review it again and will port these changes to main branch.
Oh wow it definitely has. I totally forgot about this. I could take a look today and if it's not too difficult to port to main I can do that.