The OpenGL Extension Wrangler Library (GLEW). A library that generates code to make it possible to write portable applications that use OpenGL extensions. Check it out at http://glew.sourceforge.net This simple ebuild builds the code and installs the .so and documentation. I guess this would be place in media-libs/glew. Depends on wget to build.
Created attachment 23460 [details] glew-1.1.4.ebuild
Created attachment 23565 [details] slightly modified ebuild The original ebuild installed in /lib /bin and /include. This small change installs correctly in /usr/lib, /usr/bin, and /usr/include.
glew-1.2.4 is out. just changed the ebuild name and it seems to work so far.
I was looking to add this into the portage tree as well. Does it normally take this long to add a new ebuild?
It does when there's an extreme shortage of people with spare time, some knowledge and an interest in a given area (e.g., X). =\ Also, I think it's important to ensure there's some demand for an ebuild before adding it. I do see a few CC's here and comments from a few people.
I didn't mean to come across as impatient, I was just honestly curious to the turn-around time. I wasn't even aware that ebuilds require a moderate backing to be placed in the main tree. In any case, this package will surely start drawing more demand since it is a very useful tool for GPU programming in linux. The latest nvidia drivers finally support the GL shading language, so I suspect people will start looking for this in portage. Thanks,
Stefan's into that sorta stuff.
Someone please put this in the main portage tree! I'm not doing much under OpenGL on Linux ATM, due to having an AMD64 and an ATI card, but I'm currently doing a fair bit with MinGW, using GLEW and <a href="http://bugs.gentoo.org/show_bug.cgi?id=66532">GLFW</a>. This is a v. handy dev lib, Gentoo *is* a development platform, isn't it? :) P.S. they're now at ver. 1.2.5.
Created attachment 46853 [details] ebuild for GLEW 1.2.5. Added a new ebuild: - Version bumped to 1.2.5 - Uses doins, dobin etc. rather than "make install" - Added "doc" USE flag - Removed auto code generation step, as it is length & not strictly necessary - This makes the wget dependency unnecessary - Added "~amd64" keyword (I have an AMD64; it built no problem)
I made other ebuild, which uses CFLAGS defined in make.conf.
Created attachment 47589 [details] CFLAGS version of glew-1.2.5.eduild
This package is licensed also under GLX license details here: http://glew.sourceforge.net/glx.txt
Created attachment 47644 [details] CFLAGS version of glew-1.2.5.ebuild I fixed bad patch to instalation directory (missing "/usr" in GLEW_DEST). BTW is there any possibility to add this library to partage - it's extremly useful for people that uses newer OpenGL extensions like OpenGL Shading Language, like I do.
Created attachment 47876 [details] glew-1.3.1 New version that supports core OpenGL 2.0 functionality, custom code generation for lean and mean applications, and a new function for efficient string-based extension queries.
glew-1.3.0 ebuild works fine here (x86). The revived sdljava library depends on glew. Would be nice to have it in portage.
Comment on attachment 47876 [details] glew-1.3.1 Version bump to 1.3.1
Version 1.3.2. Previous ebuild works fine.
I also would very much like to see GLEW added to portage.
See the first half of comment #5. Anyone who wants to be an X dev and who is reasonably qualified, feel free to email me.
Created attachment 58843 [details] GLEW v1.3.2 ebuild New ebuild for version 1.3.2 of GLEW. I've improved on the preceeding ebuilds a bit, mostly as far as the licensing and architechture flags are concerned.
Created attachment 58845 [details] GLEW v1.3.2 ebuild Hmm, botched that a bit. Now added the section that replaces the CFLAGS.
Hey, just looking over your ebuild, a few questions, especially since I'm not particularly familiar with this lib: 1) Is the symlink to so-1.3 necessary? 2) Is it necessary to download the "registry" txts every build? This makes the ebuild volatile, since a bad download could cause some issues...a better solution would be to take a snapshot of the "registry" and have that downloaded as a source file instead... 3) What issues did parallel builds produce? Other than that it looks well written. I'm assuming wget is required for those files, and that CFLAGs weren't applying before the Makefile was patched?
1). I am not sure that the symlink is neccessary. however, the build itself produces it, so I thought it best to include it. 2). A more elegant solution to downlaoding the registry texts every time would be to add a flag that could enable this if desired. I'll take a look to see if there is already one that would suit this, or do you know of one offhand? As to the solution you mentioned, I personally don't want to implement it, since the way it's done now is taken care of by the makefile in the "auto" directory. Anything else would take a lengthly rewrite which I'm not sure how to do. Feel free to implement it yourself however =) 3). The parallel make caused the ebuild to fail with the message that it could not find -lglew when linking.
Well, I guess the question is: how often are the registry texts updated? Is it with every version release, or more often? And how important is it to keep them up to date? I'd prefer to do something like Glibc, where a snapshot is taken from time to time.
(In reply to comment #5) > It does when there's an extreme shortage of people with spare time, some knowledge and an interest in a given area (e.g., X). =\ > > Also, I think it's important to ensure there's some demand for an ebuild before adding it. I do see a few CC's here and comments from a few people. I am also developing X apps under gentoo and it would be nice to see this lib in portage...
Stefan, I didn't notice that this had been assigned to you. I've been doing some work on this ebuild, but if you're going to maintain it I can give you what I have and stay out of your way :P
Nevermind, I'm just a Bugzilla n00b. Re-assigning to myself. I'll add a new ebuild attachment shortly for a small testing run.
Created attachment 63275 [details] glew-1.3.3.ebuild Based on the 1.3.2 ebuild, with a new USE-flag for triggering spec file downloading. Testing would be appreciated.
Of course, keyword = USE-flag if anyone's confused.
*** Bug 100331 has been marked as a duplicate of this bug. ***
Alright, I just added this package to the Portage tree as ~x86. Barring any issues I'll get the relevant arch teams involved in adding the rest of the keywords. Thanks for all your work :)
Created attachment 85763 [details] Proposed ebuild of glew-1.3.4 Makefile patched to remove -s argument of install command. Otherwise it would strip all symbols from almost everything, without any attention to FEATURES="nostrip" flag. As a result, it produced unusable static library, with noting in it. Now, depending from FEATURES="nostrip" flag, ebuild itself stripes symbols or not.
(In reply to comment #32) > Created an attachment (id=85763) [edit] > Proposed ebuild of glew-1.3.4 > Change added to Portage in 1.3.4-r1, thanks. Next time, please file a new bug with this sort of information, and attached a diff against the old ebuild version. It makes things easier to track :)
