Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v3.4/glfw: add support for GLFW version 3.4 (and future 3.4.x versions) #393

Open
Jacalz opened this issue Feb 25, 2024 · 7 comments · May be fixed by #400
Open

v3.4/glfw: add support for GLFW version 3.4 (and future 3.4.x versions) #393

Jacalz opened this issue Feb 25, 2024 · 7 comments · May be fixed by #400

Comments

@Jacalz
Copy link
Collaborator

Jacalz commented Feb 25, 2024

The initial release of GLFW v3.4 was released a few days ago, see https://github.com/glfw/glfw/releases/tag/3.4. I'm opening this issue to keep track of the work of adding the necessary support here.

@dmitshur
Copy link
Member

dmitshur commented Mar 6, 2024

v3.3/glfw is its own module, separate from the top-level module that has the older versions v3.{0,1,2}/glfw. That seems to be working well, so I expect we can repeat that pattern and also have v3.4/glfw as another nested module.

@dmitshur dmitshur changed the title Add support for GLFW v3.4 v3.4/glfw: add support for GLFW version 3.4 (and future 3.4.x versions) Mar 6, 2024
@Jacalz
Copy link
Collaborator Author

Jacalz commented Mar 6, 2024

Agreed. That is a nice concept as it means that any potential dependencies won't have to be pulled in from other glfw versions in this package.

@Jacalz
Copy link
Collaborator Author

Jacalz commented Mar 6, 2024

It looks like #272 might be revolved together with this.

@Geo25rey
Copy link

Geo25rey commented Apr 14, 2024

Hey all, I was able to hook the bindings from the v3.3 folder into glfw v3.4 with minimal changes to the code. However, I had to rely on the built in CMake build system in the upstream repo because it does some weird things to generate the wayland-protocol deps.

I managed to get the linux+wayland build tags working fine, but there seems to be some major issues with crashing the entire login session on Gnome DE whenever a glfw app is closed. It might be worthwhile to disable wayland atm until these issues are resolved.

I haven't tested any other build configs, but I can share what I have so far if anyone would like to test on their local environment.

Edit:
The issue with Gnome seems to be a bug within Gnome and nothing to do with GLFW. They have a fix in place on their main branch and 🤞hopefully, the fix will be included in their upcoming release at the end of this week.

@Jacalz
Copy link
Collaborator Author

Jacalz commented Apr 30, 2024

Hi @Geo25rey. Thanks for looking into this, we really appreciate it (and sorry for the late reply). About the Wayland-protocol generation, I wonder if they are just doing something similar to what we are doing in scripts/generate-wayland-protocols.sh? Maybe we can patch our script to be compatible instead of needing CMake? If you want to, you could open a draft PR and we can get more eyes looking at it :)

@Geo25rey
Copy link

About the Wayland-protocol generation, I wonder if they are just doing something similar to what we are doing in scripts/generate-wayland-protocols.sh?

They use CMake for dependency management and this includes Wayland Protocol headers.

Maybe we can patch our script to be compatible instead of needing CMake?

I tried to do that, but many of the names are in new and different formats and would certainly break the script for the previous GLFW 3.3 version.

If you want to, you could open a draft PR and we can get more eyes looking at it :)

I will probably get to it Friday or Saturday.

@Jacalz
Copy link
Collaborator Author

Jacalz commented Apr 30, 2024

I tried to do that, but many of the names are in new and different formats and would certainly break the script for the previous GLFW 3.3 version.

You might be able to copy it and adapt it to v3.4 but still keep the old one for v3.3.

@Geo25rey Geo25rey linked a pull request May 5, 2024 that will close this issue
43 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants