glfw: tracking issue for ensuring upstream patches land #95

New issue

Closed

opened 2021-11-23 18:11:21 +00:00 by emidoots · 5 comments

emidoots commented

2021-11-23 18:11:21 +00:00

(Migrated from github.com)

do not rely on undefined behavior in glfwSetWindowIcon for X11 https://github.com/glfw/glfw/pull/1986
Fix undefined behaviour in X11 keypress handling https://github.com/glfw/glfw/pull/1989
Add possible errors comment https://github.com/glfw/glfw/pull/2007
Add possible error comment https://github.com/glfw/glfw/pull/1998
update docstring which inaccurately says GLFW_CONTEXT_REVISION is a window hint https://github.com/glfw/glfw/pull/1992
github.com/hexops/mach@7d47233d7a

- [x] do not rely on undefined behavior in glfwSetWindowIcon for X11 https://github.com/glfw/glfw/pull/1986 - [x] Fix undefined behaviour in X11 keypress handling https://github.com/glfw/glfw/pull/1989 - [x] Add possible errors comment https://github.com/glfw/glfw/pull/2007 - [x] Add possible error comment https://github.com/glfw/glfw/pull/1998 - [x] update docstring which inaccurately says GLFW_CONTEXT_REVISION is a window hint https://github.com/glfw/glfw/pull/1992 - [x] https://github.com/hexops/mach/commit/7d47233d7a5a97241ad16a148c153831ce5d555d - https://github.com/ziglang/zig/pull/10202 - https://github.com/ziglang/fetch-them-macos-headers/pull/15 - [x] https://github.com/hexops/mach/issues/102

👀 1

InKryption commented

2021-12-05 16:53:45 +00:00

(Migrated from github.com)

Should add https://github.com/glfw/glfw/pull/2007

👍 1

emidoots commented

2021-12-28 11:14:05 +00:00

(Migrated from github.com)

@iddev5 @AliChraghi FYI, my general thought process is that:

It's unlikely there will be more patches like these to glfw/glfw, possibly patches to improve comments/docs/etc but probably not critical things we need to patch in our vendored copy of GLFW.
My general rule of thumb is that we use the upstream version in all cases, except if there is a bug caused by using our Zig compilation method.
- OK: we patch undefined behavior in our vendored copy (with a PR sent upstream which is being tracked to ensure we do in fact land it upstream), because our behavior with Zig (which has ubsan on by default) would differ from the normal experience of someone using GLFW with e.g. a C compiler.
- Not OK: we patch our vendored copy to fix Wayland bugs, for example. We would instead need to wait for those to be officially fixed upstream by sending a PR and waiting for a released version, and only then we can adopt them here in main.
Any new patches to our vendored copy from here on out should require a proper .patch file applied as part of update-upstream.sh, to prevent issues like #149

@iddev5 @AliChraghi FYI, my general thought process is that: 1. It's unlikely there will be more patches like these to glfw/glfw, possibly patches to improve comments/docs/etc but probably not critical things we need to patch in our vendored copy of GLFW. 2. My general rule of thumb is that we use the upstream version in all cases, except if there is a bug caused by using our Zig compilation method. * OK: we patch undefined behavior in our vendored copy (with a PR sent upstream which is being tracked to ensure we do in fact land it upstream), because our behavior with Zig (which has ubsan on by default) would differ from the normal experience of someone using GLFW with e.g. a C compiler. * Not OK: we patch our vendored copy to fix Wayland bugs, for example. We would instead need to wait for those to be officially fixed upstream by sending a PR and waiting for a released version, and only then we can adopt them here in `main`. 3. Any new patches to our vendored copy from here on out should require a proper `.patch` file applied as part of `update-upstream.sh`, to prevent issues like #149

iddev5 commented

2021-12-28 11:19:27 +00:00

(Migrated from github.com)

I agree. Such patches should only make minor but critical changes i.e things like comment or misinformation or doc patches doesnt seems important. And at the same time should not add new feature or make difference from glfw (as was your 2.b point :))

alichraghi commented

2022-05-21 11:43:02 +00:00

(Migrated from github.com)