Summary: | games-emulation/sdlmame-0.159 version bump | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Ryan Koudys <ryan> |
Component: | [OLD] Games | Assignee: | Gentoo Games <games> |
Status: | RESOLVED DUPLICATE | ||
Severity: | enhancement | CC: | carlphilippreh, henson, jeremy.william.murphy, mgorny |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
0.152 ebuild proposal
QA patch rewritten ebuild for 0.159 Fix sdl_ttf include path Updated QA patch for 0.159 Updated debugger-linking patch for 0.159 |
Description
Ryan Koudys
2014-01-01 08:21:22 UTC
Created attachment 368752 [details]
0.152 ebuild proposal
double check it , i'm not accurate with ebuild writing.
Compiled fine on my machine.
No diff yet available on mamedev.org.
I'm attaching the QA patch because i had to rewrite it.
Created attachment 368754 [details, diff]
QA patch rewritten
all others patchs are the same and applied fine, i've just renamed all.
leave the patch support in so the ebuild doesn't have to change to support them. I had to make some changes to the ebuild to get it compile here (~amd64), detailed below. I also had to unmask >=dev-lang/lua-5.2.3-r1, app-admin/eselect-lua, and games-emulation/sdlmame. The changes to the ebuild were: - Change the flag in the RDEPEND for libsdl from 'audio' to 'sound' - Had to add 'edos2unix src/emu/cpu/m68000/m68k_in.c' to src_prepare() (real fix, which obviously never got into upstream, is described in bug #489118) I also had to use the QA patch attached here, and had to bump the revisions of the 'no-opengl', 'system-lua', and 'debugger-linking' patches to 0.152. Also, on the third time through compiling this beast, I also discovered that I had to bump 'mame-0.139.ini.in' to 0.152. Shouldn't the ebuild detect that all its files are in the tree before getting all the way to the end and failing miserably when it can't find it? :-P Also, once you unmask and reinstall lua 5.2, you have to do an 'eselect lua set 1', otherwise sdlmame will complain throughout the compile about a missing PKGSPEC something or other; it will fail to link at the very end. Ultimately, though, if you perservere and do all these things, it will build and the resulting binary will work. :-) (In reply to James L. Hammons from comment #4) > I had to make some changes to the ebuild to get it compile here (~amd64), > detailed below. I also had to unmask >=dev-lang/lua-5.2.3-r1, > app-admin/eselect-lua, and games-emulation/sdlmame. The changes to the > ebuild were: > > - Change the flag in the RDEPEND for libsdl from 'audio' to 'sound' > - Had to add 'edos2unix src/emu/cpu/m68000/m68k_in.c' to src_prepare() > (real fix, which obviously never got into upstream, is described in bug > #489118) > > I also had to use the QA patch attached here, and had to bump the revisions > of the 'no-opengl', 'system-lua', and 'debugger-linking' patches to 0.152. > Also, on the third time through compiling this beast, I also discovered that > I had to bump 'mame-0.139.ini.in' to 0.152. Shouldn't the ebuild detect that > all its files are in the tree before getting all the way to the end and > failing miserably when it can't find it? :-P > > Also, once you unmask and reinstall lua 5.2, you have to do an 'eselect lua > set 1', otherwise sdlmame will complain throughout the compile about a > missing PKGSPEC something or other; it will fail to link at the very end. > > Ultimately, though, if you perservere and do all these things, it will build > and the resulting binary will work. :-) eselect lua is crap. I personally will never support such broken approaches. I'd rather add a new package lua-vanilla to the tree, because I am quite sick of the hackery the current lua ebuild maintainers are doing. So I'd vote for dropping the system-lua patch here completely. Looks way saner than relying on that broken stuff some people are shipping in gentoo without QA stepping in. yep. the lua situation is holding up stablizing too so I agree with using the embedded version for now and going back to the system version in the future if possible. OK, so I went and removed the lua patch and removed the 'without lua' configuration option, and it built and runs just fine. I have no dog in the lua fight; I just want to see this hit the tree sooner than later. :-) (In reply to James L. Hammons from comment #7) > OK, so I went and removed the lua patch and removed the 'without lua' > configuration option, and it built and runs just fine. Are you sure you attached the correct ebuild? I still see the system lua patch and disabling code there... Oh, sorry, you didn't attach any new ebuild at all. I updated the prototype ebuild for 0.159, with a couple changes: * Updated QA patch and debugger-linking patch to apply cleanly * 0.159 wants libsdl2, not libsdl * The no-opengl patch is in upstream now * It looks for sdl_ttf in include/SDL2, not SDL, so added sdl_ttf.patch It compiles cleanly and seems to work ok. The ebuild definitely isn't tree ready, but hopefully a dev can tune it up and get it in at some point, and users can try it out in an overlay. Created attachment 398756 [details]
ebuild for 0.159
Created attachment 398758 [details, diff]
Fix sdl_ttf include path
Created attachment 398760 [details, diff]
Updated QA patch for 0.159
Created attachment 398762 [details, diff]
Updated debugger-linking patch for 0.159
(In reply to Paul B. Henson from comment #12) > Created attachment 398758 [details, diff] [details, diff] > Fix sdl_ttf include path This is wrong. You should use sdl2-ttf since you switched to libsdl2. (In reply to Michał Górny from comment #15) > > This is wrong. You should use sdl2-ttf since you switched to libsdl2. Ooops. Remember I said "hopefully a dev can tune it up" ;)? Thanks, I didn't notice there was a separate ttf package for sdl2 and it seemed to work fine with the kludge I made. I'll try to compile it again with the right dep and ditch the header location patch. Another thing I noticed is that it doesn't seem to be using the /etc/games location to look for ini files. The current ebuild sets INI_PATH in OPT_FLAGS, which seems to be referenced in src/osd/sdl/sdl.mak: CCOMFLAGS += $(OPT_FLAGS) However, it doesn't show up during the actual compile: ebuild /usr/local/portage/games-emulation/sdlmame/sdlmame-0.159.ebuild compile > /tmp/mame.out 2>&1 grep INI /tmp/mame.out I ended up putting it in CFLAGS instead, and it works. Not sure what's going on there. the updated QA patch is incomplete, e.g. the upstream Makefile still hardcodes 'pkg-config' instead of using '$(PKG_CONFIG)' *** This bug has been marked as a duplicate of bug 556642 *** |