3 ms·

Basically: to make OpenGL apps in Go you used to have to install a bunch of headers and libraries, and it was a real pain. We fixed it a long time ago, but peo

• pjtr 12y ago
  Why didnt' you simply put a big red flashy banner on the go-gl repo pointing to the preferred repo?
  • slimsag 12y ago
    It's explained pretty well in the doc -- but basically for consistency and ease of use for newcomers. No point in having a bunch of "DONT USE THIS CODE" repositories everywhere. Its confusing. Instead, we have a way going forward to have people see the latest and greatest code with minimal cruft.
• lloeki 12y ago
  > to make OpenGL apps in Go you used to have to install a bunch of headers and libraries, and it was a real pain. Not quite the case (brew install glew glfw3 on OSX), but the problem is more that it requires cgo at all. One or two years ago I tried to use a package (I can't remember the name of and I'm at work) which was pure go for GL bindings, generated from the OpenGL specs, but it lacked a few wrappings and boxings here and there, making some calls particularly ugly and really not trivial, so I fell back to go-gl/gl (which requires glew). Of course you still need to link with something (such as glfw) that pops up a window, but that's one thing less to achieve cross-compilation. BTW with recent Go it works fine when built as a dylib, it's just tougher to distribute (on OS X at least, due to stored paths). From a more general dependency management PoV, I'm a bit anxious about how this is handled though, as this sets an uneasy precedent. "Forcing" the change is unwelcome this way as it significantly breaks the compatibility promise. Short of solutions like semantic versioning dependency management systems, the Go community has been idiomatically handling such incompatibilities at the library name level (foo, foo2, foo3 or bar.v1, bar.v2, bar.v3, or straight up another name). When handling such situations I'd rather have deprecation warnings on the README and when calling the code, pointing people to the new location, but keeping my current code working. Anyway, I'm really glad things have progressed on the pure Go front as this really makes things easier for everyone. Vendoring glfw 3.1 is an interesting strategy.
  • slimsag 12y ago
    > Not quite the case (brew install glew glfw3 on OSX) Sure, for OS X and Linux distros. What about Windows? No external dependencies is better all around. > but the problem is more that it requires cgo at all. You'll always be using CGO to make C calls, which OpenGL is. > One or two years ago I tried to use a package (I can't remember the name of and I'm at work) which was pure go for GL bindings, generated from the OpenGL specs, but it lacked a few wrappings and boxings here and there, making some calls particularly ugly and really not trivial, so I fell back to go-gl/gl (which requires glew). You'd be talking about Glow, most likely. For which the document outlines, is replacing go-gl/gl. It's gotten a lot nicer and works much better. > Of course you still need to link with something (such as glfw) that pops up a window, but that's one thing less to achieve cross-compilation. BTW with recent Go it works fine when built as a dylib, it's just tougher to distribute (on OS X at least, due to stored paths). You don't have to deal _at all anymore_ after this change! =) The Go tool builds the C sources directly, as it would Go source files. No external library installation needed: it's included. > From a more general dependency management PoV, I'm a bit anxious about how this is handled though, as this sets an uneasy precedent. "Forcing" the change is unwelcome this way as it significantly breaks the compatibility promise. Short of solutions like semantic versioning dependency management systems, the Go community has been idiomatically handling such incompatibilities at the library name level (foo, foo2, foo3 or bar.v1, bar.v2, bar.v3, or straight up another name). When handling such situations I'd rather have deprecation warnings on the README and when calling the code, pointing people to the new location, but keeping my current code working. I promise you personally that we are fully aware of the issues and breaking backwards compatibility with this change. For that exact reason we've announced it loud and clear. Myself and many other people whom I consider very smart were involved in this decision, which was not taken lightly. We chose what we believe to be the best path: breaking compatibility today, for a future where we will likely never have to again. I enjoyed reading your thoughts, and I think this will do you a lot of good should you try using the packages again =)
    • lloeki 12y ago
      > You'll always be using CGO to make C calls, which OpenGL is. you're right. > You'd be talking about Glow, most likely Found it! https://github.com/chsc/GoGL https://github.com/chsc/GoGL > breaking compatibility today, for a future where we will likely never have to again. I hope so! The new scheme looks solid enough not to have to change again. Great work. Thanks for your clear and supportive answers :-)