The media-libs/glut ebuild currently cuts glut out of Mesa-5.0, then builds and installs it. After 5.0, Mesa split out GLUT into a separate tarball but portage was never updated. So, the questions I have are: - How do we handle versioning? MesaGLUT-6.5.1 still installs libglut.so.3.7.1, so should we version it as 6.5.1 or 3.7.1-rX (where X will continually increase over time)? - How should we name it? Should we put it under media-libs/glut, or create media-libs/mesaglut and phase out media-libs/glut over a suitable amount of time? - MesaGLUT uses the mesa build system and requires both MesaLib and MesaGLUT tarballs. For this reason some code has to be copied from the mesa ebuild. Should we create an eclass for this shared code?
Created attachment 101470 [details, diff] diff of changes between Mesa-5.0/src-glut and Mesa-6.5.1/src/glut/glx There are no big changes here so this whole thing is low priority...
Created attachment 101471 [details, diff] glut-6.5.1.ebuild Preliminary ebuild for MesaGLUT
Why not just use media-libs/freeglut?
(In reply to comment #0) > The media-libs/glut ebuild currently cuts glut out of Mesa-5.0, then builds and > installs it. > > After 5.0, Mesa split out GLUT into a separate tarball but portage was never > updated. Has any code changed since then? What's the point of doing this, when you still need at least 2/3 tarballs anyway? > - How should we name it? Should we put it under media-libs/glut, or create > media-libs/mesaglut and phase out media-libs/glut over a suitable amount of > time? Why change the name? It's the same GLUT implementation as it was before. > - MesaGLUT uses the mesa build system and requires both MesaLib and MesaGLUT > tarballs. For this reason some code has to be copied from the mesa ebuild. > Should we create an eclass for this shared code? I just don't see any motivation for changing it at this point, particularly considering that you should be using freeglut instead and it is the default for the glut virtual.
A few weeks ago I had to spend a lot of time diagnosing multilib-related build/install failures with the current media-libs/glut. If you've ever spent half a day or longer working through libtool code, you'll have some grasp of the pain I was feeling. The problems were basically because the build system was so out of date, so I put it on my todo list to figure out why glut disappeared from mesa after 5.0, and this bug is a result of my findings. There are some code changes but they are all small. I don't see why that is a reason to ignore this though, treat this as a "version bump" bug? With this new version we can also drop all the current ebuild hackery and patches that we have for this package. As for naming, note that as one of my suggestions I did suggest that we keep it under media-libs/glut. OTOH, reasons why we might want to change: - It's not glut, its mesa's implementation of glut. mesa-glut being called glut (as it is right now) is comparable to mesa being called "media-libs/opengl" - Versioning gets potentially confusing/inconsistent, depending on the answer to my other question. If we put the new version in media-libs/glut as glut-6.5.1, then it's kinda confusing when upgrading from 3.7.1 (yet the actual glut API installed is still version 3.7.1 and this is not going to change any time soon). Alternatively, we could name it media-libs/glut-3.7.1-rX, but the number X would potentially grow very large over time, and this doesn't feel like what the -r notation is intended for. As for freeglut, I got the impression from games developers a few weeks ago that freeglut is not ready for "prime-time" and also does not work with everything that uses glut. It also does not work with internal software here, fullscreen and mouse input do not work. I'll be filing a separate bug report for that once I have investigated. If I'm wrong about freeglut, then I guess we could close this bug, mask media-libs/glut and schedule for removal?
(In reply to comment #5) > A few weeks ago I had to spend a lot of time diagnosing multilib-related > build/install failures with the current media-libs/glut. If you've ever spent > half a day or longer working through libtool code, you'll have some grasp of > the pain I was feeling. The problems were basically because the build system > was so out of date, so I put it on my todo list to figure out why glut > disappeared from mesa after 5.0, and this bug is a result of my findings. Ah, finally a reason! =) Moving away from the autotools build and using Mesa's weird custom build system instead is questionable, but if it's easier this way... > - It's not glut, its mesa's implementation of glut. mesa-glut being called glut > (as it is right now) is comparable to mesa being called "media-libs/opengl" No, it is the original GLUT implementation imported into Mesa with some small changes made to keep it building, unfriendly license and all. It is rarely touched, so I don't see this revision number growing much. Certainly not for every release. One creative versioning option (if it works) is something like 3.7.1_p6.5.1. > As for freeglut, I got the impression from games developers a few weeks ago > that freeglut is not ready for "prime-time" and also does not work with > everything that uses glut. It also does not work with internal software here, > fullscreen and mouse input do not work. I'll be filing a separate bug report > for that once I have investigated. Give freeglut CVS a try, I think some of this stuff may have shown up since the last release. If so, I would prefer to selectively patch issues into freeglut than continue touching glut.
Seems better than last time, however freeglut is grabbing the Alt+FX keypresses even though our app doesn't listen for them. This is inconvenient in our development environments as these keys are mapped to change virtual desktop, i.e. we run the fullscreen app on one and some terminals/development utilities on another, and we switch between them regularly.
Haven't had time to look at the Alt+Fx issue yet, so filed a bug upstream http://sourceforge.net/tracker/index.php?func=detail&aid=1647258&group_id=1032&atid=101032
Have crawled throught the source of all availible implementations. After discussion with remi we will keep just freeglut to minimalise the fuzz about what implementation is the best. Thus closing this one as wontfix cause the package will have no point in the tree. Up to now (mesa-7.5)it is just old glut with few tiny patches to make it compile fine, so it has really no point.
