go.mod support #240
Comments
|
Most definitely. I've already started using it on my personal projects. I'm waiting for 3.3 for the changes |
GLFW tag 3.3-stable @ glfw/glfw@e4e9581 * Fix C Include & address GLFW v3.3 removals * Glfw moved away from posix_tls.c to posix_thread.c (this reflects that they now contain more than TLS) * Glfw moved away from win32_tls.c to win32_thread.c (same as above) * Glfw removed wayland-.*-unstable-v1-client-protocol.c * Glfw added wl_platform.h * Glfw removed GLFW_USE_RETINA, _GLFW_USE_CHDIR and _GLFW_USE_MENUBAR compile-time macros * Glfw removed support for MIR * Address deprecations of glfw 3.3 * Glfw deprecate glfwSetCharModsCallback * Glfw deprecate the window parameter of glfwGetClipboardString and glfwSetClipboardString, NULL can be used as the window argument * Add glfw.SetClipboardString(string) and glfw.GetClipboardString() function (no Window type required) * Use casting and clang-format c code * Use casting instead of callback in C helpers (same as #219) * Update travis * Fix Darwin build tag Fixes: #245, #255, #240, #230, #170
|
FYI, support for glfw v3.3 landed in #256 (this is the last open issue with the glfw-3.3 tag). I note that there does exist a go.mod file in, e.g. https://github.com/go-gl/glfw/blob/master/v3.3/glfw/go.mod. It's empty because glfw doesn't have any go dependencies. To make using go-gl/glfw easier as a go module, I guess go-gl/glfw needs a tag. The question then becomes: what should the tag be? I guess that our tag needs to evolve independently of the glfw/glfw tag. In which case "v1.0" might be a reasonable tag, if people felt that the API was reasonably stable. Another question on my mind is "How does the /v3.3/ in the go-glfw path interact with go mod's notion of major versions? Is there any conflict there?". I'm going to remove the glfw-3.3 tag since this issue doesn't have much to do with glfw-3.3 anymore - at least the constraint is gone, just the need to solve the obvious problems. /cc @dmitshur who I bet/hope has opinions on the matter :) |
|
TL;DR: I'm closing this issue on the grounds that go modules work today. Please file other issues if there are specific things which are broken (tags -> #188, go mod vendor -> #251). Tags were actually discussed in #188 - I suppose we should continue that discussion there. A specific issue of module support (go mod vendor) was discussed in #251 (and hopefully addressed in #258). I suggest continuing the tag discussion in #188, and closing this issue for now, because I don't believe that we do anything right now that inhibits using go mod. We don't have tagged releases, but since:
... I don't believe that lacking versions is preventing anyone form using go modules today. I think the versions would be nice to have, though. We just have to figure out a scheme that a few people think will work. Note that if there is some sense that I've missed that prevents go modules support, by all means we can reopen this issue. |
Are you planning to add support for
go modand versioned releases?The text was updated successfully, but these errors were encountered: