Use go-gl/glow instead of external glew in go-gl/gl
43 views
Skip to first unread message
Fabian Wickborn
Aug 15, 2014, 5:10:53 AM8/15/14
to go...@googlegroups.com
I wonder whether it would be good thing for go-gl/gl to use go-gl/glow instead of the external glew library. If this were the case one would be able to keep using the more Go-idiomatic API in go-gl/gl in my projects, without having to care of building/deploying glew.
Personally, I'm currently struggling with building a static linked version of glew and go-gl/gl on Windows with MinGW (32/64), so every time I deploy something that uses go-gl/gl I need to make sure it can access a glew DLL. I'd rather have an executable that is statically linked as much as possible (it would always require the OpenGL DLLs of course).
So, are there any plans to get rid of glew now that go-gl/glow is around? Or are there any potential reasons why this would be a really bad idea? I'm interested in hearing your thoughts.
Peter Waller
Aug 15, 2014, 5:20:33 AM8/15/14
to go...@googlegroups.com
Hi Fabian,
One goal of the go-gl project is to avoid breaking API compatibility.
We occasionally break the rule if we must but try not to for long
stretches of time. And when we do break it, I hope we do it in a way
with minimal impact.
My current feeling is that if we ultimately want to deprecate the
`go-gl/gl` way of doing things (and move towards glow for example,
hypothetically), we have to use a new namespace, so as not to break
existing projects.
If we can move to glow under the hood for gl and not break its API, then
I'm not against it in principle unless there are other drawbacks that arise.
go-gl is a fairly informal community run project and there are a few
good voices around, so I think it would be good to see what other people
think. We're always looking for contributors and pull request reviewers,
so if you're keen to dive in, prototype and report back, it would be
interesting to hear how you get along. But we would then have to decide
together whether it was an appropriate direction to take things.
Hopefully others will chip in if there are more obvious show-stoppers or
alternative reasonable approaches.
Cheers,
- Peter
One goal of the go-gl project is to avoid breaking API compatibility.
We occasionally break the rule if we must but try not to for long
stretches of time. And when we do break it, I hope we do it in a way
with minimal impact.
My current feeling is that if we ultimately want to deprecate the
`go-gl/gl` way of doing things (and move towards glow for example,
hypothetically), we have to use a new namespace, so as not to break
existing projects.
If we can move to glow under the hood for gl and not break its API, then
I'm not against it in principle unless there are other drawbacks that arise.
go-gl is a fairly informal community run project and there are a few
good voices around, so I think it would be good to see what other people
think. We're always looking for contributors and pull request reviewers,
so if you're keen to dive in, prototype and report back, it would be
interesting to hear how you get along. But we would then have to decide
together whether it was an appropriate direction to take things.
Hopefully others will chip in if there are more obvious show-stoppers or
alternative reasonable approaches.
Cheers,
- Peter
Reply all
Reply to author
Forward
0 new messages