Optional features smp, openal, curl, and vorbis are available in the quake3 makefile (see http://svn.icculus.org/quake3/trunk/Makefile?view=markup) USE flags should be available for each of these. Reproducible: Always
Created attachment 159626 [details] Updated quake3-1.34_rc3.ebuild Ebuild with new useflags
Created attachment 159628 [details] Updated quake3-9999.ebuild SVN ebuild with new useflags
Created attachment 181319 [details] games-fps/quake3-1.36_rc1.ebuild version bump [!] may require some additional changes
The quake3-1.36_rc1.ebuild thinks my ARCH is x86, although it really is x86_64. Apparently, tc-arch-kernel returns the architecture incorrectly. Can someone reproduce it?
tc-arch-kernel is supposed to return x86 for x86_64 but whether that's what Quake needs, I'm not quite sure. On the one hand, it still builds and runs fine as a 64-bit binary. On the other hand, the makefiles do check whether ARCH is equal to x86_64 in a few places and from what I've seen, some of them might be important. There is the tc-arch function instead but that returns amd64, which is not much better.
(In reply to comment #5) > On the one hand, it still builds and runs fine > as a 64-bit binary. No - it builds a 32-bit program.
Definitely a 64-bit one here and I used that ebuild exactly as it is.
Well indeed - was not the case a month ago. However, using the ebuild without modification still results in some issues - for example, the new x86-64 QVM bytecode compiler doesn't get enabled (says "Architecture doesn't have a bytecode compiler, using interpreter"). This comes from the places you've noted as using x86_64.
Version 1.36 went gold on April 23rd. Also, someone filed a bug for an update to version 1.36. See bug 270114.
Please see bug 270114 for my reasoning why that bug is not a duplicate of this one.
Created attachment 194050 [details] games-fps/quake3-1.36.ebuild Changed make options that when openal and curl are enabled that they are linked at runtime. I'm sure there's a better way to do this.
Created attachment 194190 [details] games-fps/quake3-1.36.ebuild Removed CC="$(tc-getCC)" ARCH=$(tc-arch-kernel). Do we really need them? It seems to compile and run fine for me without them (running on amd64 system). Added voice and speex use variables. voice is to enable/disable voip. speex is to enable/disable external speex library. I must add, external speex library doesn't work with speex 1.2_beta3_p2 or 1.2_rc1 in portage (maybe need an older version?). Added USE_LOCAL_HEADERS=0. Forces use of system headers. Again works for me. Maybe we should determine if use variable would be in order for this.
Also should add: For OpenAL to work for me I had to add a link in /usr/lib64 for libopenal.so.0 to point to libopenal.so.1.7.411. OpenAL would fail on startup otherwise.
(In reply to comment #13) > Also should add: For OpenAL to work for me I had to add a link in /usr/lib64 > for libopenal.so.0 to point to libopenal.so.1.7.411. OpenAL would fail on > startup otherwise. > See bug 272192 about this issue for OpenArena. Maybe the same variable (s_alDriver) is applicable for IOQuake. Hopefully, the default for this variable can be configured during the build process.
Created attachment 194200 [details] games-fps/quake3-1.36.ebuild Changed to EAPI2. Made working the libopenal.so source change easier (borrowed form the openarena e-build). Added mumble use variable. Not official, and I have not tested as I don't use it. Would require the masked media-sound/mumble, as that is all that is available.
(In reply to comment #12) > Removed CC="$(tc-getCC)" ARCH=$(tc-arch-kernel). Do we really need them? It > seems to compile and run fine for me without them (running on amd64 system). The x86-64 JIT QVM compiler didn't get enabled with quake3-1.36.ebuild for me. I had to add ARCH="x86_64" to the make options.
Created attachment 194566 [details] games-fps/quake3-1.36.ebuild Re-added ARCH back with use check for amd64. This assures that the correct arch is returned for amd64 systems, which is x86_64. Otherwise, it will return amd64 (at least on my system). Will this have to be done for other archs? This should take care of the issue reported in comment #4 and #16.
I started to look into why smp doesn't get enable proberly (for me), even though I have the flag set. It appears that in the Makefile that it lets you enable the build option, but never sets the cflag of -DSMP. So I forced -DSMP in the build file and still doesn't work. So, after a little more searching I found the following on ioquake3's forums: http://www.ioquake.org/forums/viewtopic.php?f=12&t=91 Which basically states that smp doesn't work. I would still leave the smp flag in the ebuild in case one day it works. Does anyone else have this smp issue to verify? Also, after looking into the Makefile, it appears to support alpha, ppc64, sparc, and s390. Should these archs be added to the ebuild?
(In reply to comment #18) > I started to look into why smp doesn't get enable proberly (for me), even > though I have the flag set. It appears that in the Makefile that it lets you > enable the build option, but never sets the cflag of -DSMP. So I forced -DSMP > in the build file and still doesn't work. So, after a little more searching I > found the following on ioquake3's forums: > > http://www.ioquake.org/forums/viewtopic.php?f=12&t=91 > > Which basically states that smp doesn't work. I would still leave the smp flag > in the ebuild in case one day it works. > > Does anyone else have this smp issue to verify? > > Also, after looking into the Makefile, it appears to support alpha, ppc64, > sparc, and s390. Should these archs be added to the ebuild? > Strange. A Just download quake3-1.36.ebuild by Will Lepofsky date "2009-06-13 15:17" Install it. And run quake3-smp. I uses 2 cpu on Core 2 Duo. Pleas, make sure, that you have this option enabled in you q3config.cfg For OSP mod: cat ~/.q3a/osp/q3config.cfg | grep smp seta r_smp "1" For standard q3a: cat ~/.q3a/baseq3/q3config.cfg | grep smp seta r_smp "1" If there will be "0" -- you don't restrict ioquake3 to use smp core functions.
(In reply to comment #19) Strange indeed. Thanks for the tip. But, I should have specified in my comment that I had also set seta r_smp to "1" (found that through some research). From what I understand from looking, it doesn't really increase the game that much. But, I'm still looking into possible solutions, just haven't found any that work yet (for me).
Created attachment 195162 [details] games-fps/quake3-1.36.ebuild Cleaned up the readability a little, mainly if statements. Changed mumble to be enable only if voice (voip) is enable. Should have been that way from the begining (you need voip enabled for mumble to work).
Created attachment 195569 [details] Fix ARCH problem Today I was building ioquake3 for my Pentium III, and noticed that the bytecode compiler didn't get enabled on x86 too. Apparently, the ebuild was setting ARCH to "x86", while the Makefile was expecting it to be "i386". When I was viewing the Makefile, I found out that ARCH, if it is unset, is automatically set to the value of COMPILE_ARCH which is determined by the Makefile itself. So the ebuild really should not be setting it (ARCH will only differ from COMPILE_ARCH if cross-compiling, which I leave aside now). However, removing that from the ebuild didn't help much; it appears that ARCH is set by Portage itself to the current architecture, and as such it was overriding the value that originally ought to be set. So the solution is to unset ARCH for emake invocation, and let ioquake3 Makefile deal with it. I tested this on both x86 and amd64, and it works fine. Please give it a try.
(In reply to comment #22) Good catch. I knew there was a better way for ARCH to be set properly. This fix will probably make it work for the other supported archs (see comment #18).
Thanks for the ebuild. Btw, does USE="speex" work? (Didn't compile for me with that.)
Created attachment 209578 [details] Lots of fixes After re-thinking it, I decided to return the old form of ARCH handling. It indeed would not cause trouble with cross-compilation, and needs special handling only for two cases (x86 and amd64), for other arches we can just use tc-arch-kernel. Also, the following changes were made to the ebuild: * Cosmetic fixes * src_prepare() already starts in ${S}, remove absolute paths * Add my_arch() nested function * Remove "filter-flags -mfpmath=sse", as the Makefile uses -mfpmath=sse for x86. Drop the flag-o-matic eclass * Add id-readme md4-readme.txt voip-readme.txt to docs * Add more error checking * Fix doicon path. Add quake3-tango.png * Fix dependencies: - add curl and speex to build deps; - make openal conditional on the openal USE flag; - enabling USE_VOIP uses speex unconditionally. So the speex USE flag is redundant. * Currently compilation fails with system libspeex (media-libs/speex-1.2_rc1; also stated in comment #24). Force internal :( * Add the ability to build from SVN trunk with PV=9999 * Default the USE_*_DLOPEN settings to 0. dlopen()'ing a library might be useful if we want the program to run even if the library is missing. However, on Gentoo this is not the case; plus, a value of 1 prevents revdep-rebuild from functioning properly. Please review and test it (confirmed to work on amd64). If it works well, older attachments to this bug should be obsoleted to not to confuse users. P.S. After looking deeper in the Makefile, I discovered that currently ioquake3 can't be cross-compiled, because it builds q3lcc, a build time tool, with the target arch compiler. So the COMPILE_ARCH and COMPILE_PLATFORM stuff only makes it *look like* it can be cross-compiled. However, let's keep things fixed at least on the ebuild side. P.P.S. As noted in comment #18, we could actually add more keywords if someone tests it on alpha, ppc64, sparc or s390. Thanks.
Created attachment 210217 [details] More improvements * Drop the sed command altogether, as it has no effect now * Change the icon to svg version * Allow Makefile to override the values * Don't build q3lcc and the .qvm files, as they are not used in any way * Don't build and install .so files too, because they are only for debugging * Remove DEFAULT_LIBDIR, it has no effect * Add the my_platform() nested function * smp doesn't work on Linux, comment it out for now * Cross-compilation should work now
Created attachment 210769 [details] Yet more improvements * Depend on media-libs/libsdl[joystick,opengl,video,X] and !openal? ( media-libs/libsdl[audio] ) * Link with system zlib (available only in SVN version now) * cd to release-$(my_platform)-$(my_arch) * Don't depend on media-libs/speex while USE_INTERNAL_SPEEX=1 * TEMPDIR no longer does anything, remove it * Add GENERATE_DEPENDENCIES=0, compilation should use less resources * Remove OPTIMIZE because it gets ignored. Makefile actually recognizes the CFLAGS variable * Replace "ioq*" with explicit binary names * Use openal by default * Remove src_unpack, default implementations do what is needed
Nice! Does it actually require joystick support in SDL though? I have it enabled anyway so I don't know but I find that strange.
(In reply to comment #28) ioquake3 won't compile otherwise, and there is no configuration option to change it. Thus, there needs to be a hard dependency on media-libs/libsdl[joystick]. Please see also bug #264741. Thanks
Opened a bug upstream about ioquake3 Makefile forcing its own optimization flags: http://bugzilla.icculus.org/show_bug.cgi?id=4352
Portage now has -9999 as ~arch, which will be used instead of a 1.36 version from a local overlay. I haven't installed it yet to know what may be different between the two. You could mask the -9999.
I have placed an improved version of this ebuild in an overlay, which I plan to update regularly. See more at http://bitbucket.org/andreyv/quake3-overlay . Also, the speex issue is resolved now.
(In reply to comment #32) > I have placed an improved version of this ebuild in an overlay, which I plan to > update regularly. See more at http://bitbucket.org/andreyv/quake3-overlay . > > Also, the speex issue is resolved now. Thanks a ton! I've (finally) committed your ebuilds from your overlay, so we can finally close this bug and also 250080. Let me know if you see any problems.
Created attachment 272371 [details, diff] Always call subversion_wc_info (In reply to comment #33) While re-testing the ebuilds, I found a mistake of my own that prevents the -9999 version from building in certain conditions (see attachment). Otherwise, the ebuilds work fine on amd64. Thank you!
Thanks! Committed.
