FreeGameDev

Hi,

I've added a dependency to libGLEW to current master. I wanted to implement libglew support for a while but feared it would break things, it turned out to be almost trivial.
Now travis-ci wont break anymore because I use an extension not declared in mesa/OSX and thus it brings OpenGL parity between Windows and Linux (I previously disabled features on Linux at compile time)

For linux use your package manager to install libglew-dev(el), for Windows I've attached a zip containing libGLEW dependency files, to put in the dependencies folder.
It's from the official libGLEW binary provided here : http://glew.sourceforge.net/

Vincent

vlj {l Wrote}:For linux use your package manager to install libglew-dev(el), for Windows I've attached a zip containing libGLEW dependency files, to put in the dependencies folder.
It's from the official libGLEW binary provided here : http://glew.sourceforge.net/

I've uploaded a new dependency file (dependencies_for_0.8.2-new.zip), which includes libglew.

Cheers,
Joerg

Thanks

I can't find libglew neither on http://supertuxkart.sourceforge.net/Build_STK_on_Linux nor in https://github.com/supertuxkart/stk-cod ... INSTALL.md, so you should add then there. Note that I have created http://supertuxkart.sourceforge.net/Dependencies to make it easier to change dependencies in the future

The linux wiki page should be updated by people who know the right package name on recent distributions, please, that would help

I updated the dependencies for Debian/Ubuntu based systems on the Wiki.

Auria {l Wrote}:The linux wiki page should be updated by people who know the right package name on recent distributions, please, that would help

On Mageia and Fedora it would be "glew-devel".

Akien {l Wrote}:

Auria {l Wrote}:The linux wiki page should be updated by people who know the right package name on recent distributions, please, that would help

On Mageia and Fedora it would be "glew-devel".

Thanks, added to the wiki.

Hi,

we found out that we need to apply (at least one) patch to glew to avoid a bug, so we decided to include glew in our sources in order to be able to patch it ourselves and make sure everybody can compile it. Which means now there is no more dependency on glew.

Cheers,
Joerg

Ok. http://supertuxkart.sourceforge.net/Build_STK_on_Linux is updated accodingly.

hiker {l Wrote}:Hi,

we found out that we need to apply (at least one) patch to glew to avoid a bug, so we decided to include glew in our sources in order to be able to patch it ourselves and make sure everybody can compile it. Which means now there is no more dependency on glew.

Those are not good news. This breaks the whole purpose of having shared libraries on Linux distributions, which prevents you from having 30 different versions of the same dll as on Windows, each bloated with its set of bugs and security issues.

If you have a bug with glew, please work with upstream to get it fixed in the next version of glew. As much as possible, please refrain from bundling and modifying external libraries, it can be a big issue for packagers.

Of course it's only my opinion as a packager, your focus should stay on making a nice game. I just mean that if there's a way around maintaining your own in-source version of glew, please consider using it.

Oh, I will work with upstream glew, and it will be finally included in Debian 9.0 in 2018 :-P Or won't be included for some reason.

Static libraries have big adventage that when you tested your application, you can be sure (more or less) that it will work properly. Okay, there may be several bugs, but as long as you don't use this part of code in your application, it doesn't matter.

I have some commercial linux games (eg. Finding Teddy). I needed to manually download glew 1.8 because it wasn't statically linked. It's burdensome, isn't it? And what after several years? I will need to manually compile it, because I won't find it in any repository.

Linux with shared libraries is good, but sometimes Windows with 30 different versions of the same dll is better...

Not to mention that upstream projects can be very slow at releasing new versions; for example, Irrlicht 1.8 took half a year to a year longer to get released than STK 0.8, and we still would have to use a patched version to get the number of maximum material textures up from the low amount of 4. They may or may not change that for 1.9, but that might be a couple years off. So yeah, we decided to fork irrlicht and include it ourselves for various reasons, and if that happens with glew as well I won't be surprised. The packaging utopia of all necessary changes sent upstream and then incorporated into the project properly and released in a tinely manner has unfortunately proven itself to be quite impractical in many situations.

Maybe the best solution is to both fork and send upstream. The fork can then be removed when/if upstream releases it in their new version. This way, we get the improvement right away and upstream gets the patch.

Akien {l Wrote}:Those are not good news. This breaks the whole purpose of having shared libraries on Linux distributions, which prevents you from having 30 different versions of the same dll as on Windows, each bloated with its set of bugs and security issues.

If you have a bug with glew, please work with upstream to get it fixed in the next version of glew. As much as possible, please refrain from bundling and modifying external libraries, it can be a big issue for packagers.

The patch we had to apply can be found at https://sourceforge.net/p/glew/patches/40/. It has been reported upstream over a year ago, and has been postponed twice. In https://github.com/supertuxkart/stk-code/issues/1533 it is mentioned that for this reasons others have decided to include their own glew version.

Of course it's only my opinion as a packager, your focus should stay on making a nice game. I just mean that if there's a way around maintaining your own in-source version of glew, please consider using it.

This discussion is not new for us (e.g. viewtopic.php?f=17&t=3906&p=39632), and while I understand from where you are coming from, our focus is on delivering a working game, and I don't know a way of making sure that every distro includes a patched glew version (as mentioned before we have ad experience with that ).

Cheers,
Joerg

hiker {l Wrote}:

Akien {l Wrote}:If you have a bug with glew, please work with upstream to get it fixed in the next version of glew. As much as possible, please refrain from bundling and modifying external libraries, it can be a big issue for packagers.

The patch we had to apply can be found at https://sourceforge.net/p/glew/patches/40/. It has been reported upstream over a year ago, and has been postponed twice. In https://github.com/supertuxkart/stk-code/issues/1533 it is mentioned that for this reasons others have decided to include their own glew version.

Thanks for the links. If upstream hasn't even commented on why the are postponing it, then I understand that you have little choice but to patch your own copy of glew.
Don't hesitate to comment on the upstream patch proposal to explain why it is also needed in STK. Your game is a big reference in the FLOSS world, so that might get upstream look more closely at the patch and the bug that it fixes.

I'll eventually backport the patch to Mageia's glew package if your usage of it proves harmless for other glew features, so that I can still package your next release using the system glew. If there's an option to force the use of the system dependency instead of the embedded copy, it would be awesome :-) but I can also patch it if it's only useful for Mageia's package.

Akien {l Wrote}:Thanks for the links. If upstream hasn't even commented on why the are postponing it, then I understand that you have little choice but to patch your own copy of glew.
Don't hesitate to comment on the upstream patch proposal to explain why it is also needed in STK. Your game is a big reference in the FLOSS world, so that might get upstream look more closely at the patch and the bug that it fixes.

Done

I'll eventually backport the patch to Mageia's glew package if your usage of it proves harmless for other glew features, so that I can still package your next release using the system glew. If there's an option to force the use of the system dependency instead of the embedded copy, it would be awesome :-) but I can also patch it if it's only useful for Mageia's package.

At this stage there is no cmake option, but it should be easy enough for you to add it (just check our logs to see the options we used previously). I am not sure if we will add an easy -DUSE_SYSTEM_GLEW option - it might be used by other packager who are not aware of the problem, resulting in an unstable STK *sigh* Life is complicated (not sure if we can test in STK if we have a patched version of glew, and abort with an error otherwise).

Cheers,
Joerg