Here is an updated ebuild for desmume 0.9.6. I took the comments from bug 289758 into account and adjusted dependencies so that the gtk and glade interfaces are optional based on use flags. There do not appear to be any configure switches to enable/disable the interfaces, so this just does the following: 1. make gtk/glade dependencies optional if interface will not be used 2. remove gtk/glade binaries if installed (it's built automatically if necessary libraries are detected) Kind of odd behavior, but it works. I also added a MYRELEASE variable, which will likely need to be removed in future versions (was necessary to deal with an updated Linux release to address <a href="https://sourceforge.net/tracker/?func=detail&aid=3006049&group_id=164579&atid=832291">this bug</a>). Finally, assuming the ebuild meets with everyone's approval, I'd also like to request that this be stabilized, as desmume has been in portage since 01/15/2007 and has not yet received a stable ebuild release. Thanks. Reproducible: Always Steps to Reproduce:
Created attachment 233067 [details] games-emulation/desmume-0.9.6.ebuild usually helps to actually attach the ebuild... sorry about that
build and run fine on ~amd64
thanks for working ebuild. however even such crazy experimentator as myself have to say that stabilisation for desmume is highly questionable for any time soon by several reasons: - it has "alpha" status still strapped to it on sourceforge - it's in state of rapid development with features going back and forth (it has 3 separate gtk-based GUIs and with core part still buggy as hell!; is has openal, wifi(libpcap), wxwidgets(wxGTK) features announced but unusable) - its build system is crippled (they managed to break building of glade frontend for "release" _and_ to put unbuildable, unfinished wx-frontend in there too; their svn repository is dirty with dependency-files lying inside main source tree and they tend to randomly "lose" build-system files at will) - not to mention that this is still software of no much use for its purpose (2d rendering via opengl is not enabled by default and 3d rendering completely done in software even with osmesa involved [who the hell uses libOSMesa these days ?:\ ] )
Created attachment 243781 [details] games-emulation/desmume-0.9.6_p1.ebuild this is my ebuild for desmume and it produces UNUSABLE segfaulting binaries for some reason :\ my guess is that build system doing something funny with options passed to it and builds them incorrectly or i made a mistake i can't notice. please, make your suggestions. My system has Portage 2.2_rc67 (default/linux/amd64/10.0/desktop, gcc-4.4.4, glibc-2.12.1-r0, 2.6.35.2-v-fox-desktop x86_64). ebuild provided here by bug-reporter produces working binaries.
Created attachment 243785 [details] games-emulation/desmume-9999.ebuild svn live ebuild also with BROKEN binaries... builds fine otherwise :) can be used if reason for segfaults is found. right now svn even contain buildable wxwidgets GUI.
Bump: version 0.9.7 from February 1st, 2011 From the file ChangeLog: 0.9.6 -> 0.9.7 (r3493-r3654-r3812) General/Core: bug: fix a ton of old, broken cpu opcodes and CP15 logic bug: return Z1 and Z2 from TSC (fixes some touch logic) bug: gba slot save type detection improved bug: handle unusual rom headers more correctly bug: dont confuse motion pack commands with save memory commands bug: make cheat system a little less flaky and add AR 1.54 support bug: fix nondeterministic backup memory behaviour while rerecording bug: correct emulation of register accesses of wrong size and during powerdown bug: rewrite --cflash-path emulation bug: rewrite IPC/GX FIFO, IRQ flag generation, and wait-for-IRQ logics bug: rewrite RTC calendar handling; now supports years > 2038 enh: auto-DLDI patching for homebrew enh: --gbaslot-rom=self mounts self.nds in slot2 enh: more realistic exception handling enh: piano controller emulation enh: modular slot-1 system for exact emulation of homebrew cards Graphics: bug: edge marking colors were wrong bug: handle some "invalid" vram configurations correctly bug: convert half of geometry engine to fixed point bug: fix sprite blend+fadein/fadeout bug: improve rasterizer shadows bug: fix main memory display DMA bug: fix some raster fx timing bugs enh: add a hack for improving some non-stencil shadows Windows: bug: misc fixes and improvements to gpu viewer tools bug: sub screen layer display toggling fixed bug: fixes and improvements to ram watch, ram search, cheats list bug: fix start-paused commandline bug: fix memory leaks when sound disabled bug: improve load average calculators and add arm7 load average enh: background input support enh: add vsync option enh: support more knobs on joysticks enh: import cheats from R4 database enh: add xinput rumble for 360 pads Linux/OSX: bug: crash less in recent roms list enh: Add horizontal screen layout and swap screen ability to gtk frontend (noodlebox) enh: Big improvement to joystick support, support complex configurations and multiple devices (noodlebox)
One problem with the attached ebuilds is that they don't take into account that currently gtk and similar deps are automagic in nature so it will require a configure.ac patch to fix as I mentioned in bug #289758.
0.9.7 is in tree, for other issues please open separate bugs.
Hanno, I appreciate you adding this to the tree, but I'm curious - why did you remove all of the optional USE flags? That seems like a step backwards, especially since there's no reason (that I'm aware of) those features/dependencies are actually required. Sorry for the delayed response - just getting a chance to follow up on this.
@Jared B.: Look the comment above, the issue is that making those optional this way causes so-called automagic dependencies and we don't want them in Gentoo. This issue is tracked in #289758, but so far nobody stepped up to patch configure.ac accordingly to implement proper on/of-switches for those features.
ok, thanks for the clarification. I'll take a look and see if it's something I can do myself.
