Please add this patches to games-emulation/snes-9x:http://www.snes9x.com/phpbb2/viewtopic.php?t=3703
Created attachment 178934 [details] snes9x-gtk 1.51_p61 ebuild Instead of adding the patches to the old ebuild, I made a new ebuild for the GTK+ port exclusively. Partly since it can be installed alongside the original Snes9x and partly since this was easier :) Also available in roslin uberlay.
Thank you!
Created attachment 179451 [details] Updated ebuild Bumped, added a missing dep and two patches from Mandrake PLF.
Created attachment 179452 [details, diff] as-needed fix
Created attachment 179454 [details, diff] cheat editor fix
Created attachment 216916 [details] snes9x-gtk 1.52 Adding most recent ebuild from roslin uberlay. Starting with 1.52, the GTK+ is now packaged with the core.
The snes9x-gtk 1.52 ebuild works GREAT. No extra patches are required (just in case that wasn't clear from the last post), and the new interface works very well. It appears that the developers are treating the GTK and command-line ("UNIX") versions as separate ports (for more info: http://snes9x.com/phpBB2/viewtopic.php?t=4542). With that in mind, it may make sense to split this into its own ebuild as previously suggested. If so, the original snes9x package should be separately updated to 1.52 as well. Alternatively, it looks like this could still be handled as a single package if desired, using the GTK USE flag to determine whether the GTK or UNIX (or both?) version is installed. It shouldn't require too much work to modify the ebuild to support this. as it appears that you would simply compile/make from a different directory. I'll even volunteer to work on this if this is the preferred approach. Either way, though, I'd definitely like to see this added to the official tree. Much thanks to Michal for getting this working so well. :-)
Glad you like it :) Anyway, both ports have separate build systems and different configure options. I don't really think the extra complexity is worth it. Also, what if snes9x-gtk is updated independently of the main port? All things considered, it's probably safer to keep them separate.
On a semi-related note: does hq*x filter compile for you in a reasonable time ? With under 1GB memory (on x86), it seems to take ages (after several minutes, when system seemed to freeze from resource consumption, I've simply aborted compilation).
Indeed, there are two files that need 200-300 MB to compile. One of them is the filter you mention. The other seems to be tile.cpp, which has one giant preprocessor macro. This seems kind of much. Upstream is considering adding an option to disable the offending filter. The other file seems like an issue with the snes9x core in general.
Actually, tile.cpp is a bit slow (takes about 3min here), but it's that filter, that's the killer. I've never managed to wait long enough to finish (and I waited at least as long as for tile.cpp) and system becomes nearly completely unresponsive. However... If I take the older version of the filter (one, where Interp* where functions, not macros) and add '#define inline' to disable explicit inlines, that file does compile in a decent time. I'm still unsure, whether it's a bug in code or in gcc.
I don't think bug 309283 should be considered a dependency for this bug. The rationale, according to the comment in the other bug, is "It's preferred to build a 32bit version of games-emulation/snes9x". This may or may not be true (I've never seen this mentioned elsewhere, but then I've never looked for it), but I have a 64-bit version compiled on my system and it runs perfectly fine. I've not seen any reliability, compatibility, or performance issues. Having the ability to build/run a 32-bit binary is fine, but it shouldn't be a requirement, nor should the 32-bit glade dependency delay potential usage of the 64-bit version.
1.52 in portage
