Sdlmame is the new port of mame to sdl by mamedev rbelmont putting to use the new mame rendering system. It's really good and makes xmame look like the pos it is (imho). I made an ebuild for it based on the xmame ebuild, please feel free to suggest any possible improvements. It has been tested on x86 and amd64, but should work on ppc and ppc64 as well (at least insofar as sdlmame does). I have set fetch-restrictions since the website blocks wget's useragent and I don't know how/if I should circumvent that in an ebuild. I commented out the voodoo dynarec because I get an error at the linking phase with this.
Created attachment 95036 [details] sdlmame-0.108.ebuild
Created attachment 95037 [details] sdlmame-0.108.ebuild
*** Bug 145022 has been marked as a duplicate of this bug. ***
Created attachment 95841 [details] sdlmame-0.108_p1.ebuild Tidied ebuild. Sample usage: mameat -rompath . -antialias -filter -video opengl your-rom.zip Version 0.108_p2 does not compile, though: In file included from src/sdl/video.c:32: /usr/include/pthread.h:735: error: syntax error before '*' token
triend the new .108_p3 but it also failed to compile. src/sdl/dview.c:3:32: error: gconf/gconf-client.h: No such file or directory src/sdl/dview.c: In function 'dview_expose': src/sdl/dview.c:15: warning: unused variable 'pcol' src/sdl/dview.c:14: warning: unused variable 'prow' src/sdl/dview.c:13: warning: unused variable 'tcol' src/sdl/dview.c:12: warning: unused variable 'trow' src/sdl/dview.c: In function 'dview_class_init': src/sdl/dview.c:321: error: 'GConfClient' undeclared (first use in this function) src/sdl/dview.c:321: error: (Each undeclared identifier is reported only once src/sdl/dview.c:321: error: for each function it appears in.) src/sdl/dview.c:321: error: 'conf' undeclared (first use in this function) src/sdl/dview.c:321: warning: implicit declaration of function 'gconf_client_get_default' src/sdl/dview.c:322: warning: ISO C90 forbids mixed declarations and code src/sdl/dview.c:326: warning: implicit declaration of function 'gconf_client_get_string' src/sdl/dview.c:326: warning: assignment makes pointer from integer without a cast make: *** [obj/mamed/sdl/dview.o] Error 1 make: *** Waiting for unfinished jobs.... !!! ERROR: games-emulation/sdlmame-0.108_p3 failed. Call stack: ebuild.sh, line 1539: Called dyn_compile ebuild.sh, line 939: Called src_compile ebuild.sh, line 1248: Called games_src_compile games.eclass, line 136: Called die
(In reply to comment #5) > triend the new .108_p3 but it also failed to compile. > > src/sdl/dview.c:3:32: error: gconf/gconf-client.h: No such file or directory > src/sdl/dview.c: In function 'dview_expose': > src/sdl/dview.c:15: warning: unused variable 'pcol' > src/sdl/dview.c:14: warning: unused variable 'prow' > src/sdl/dview.c:13: warning: unused variable 'tcol' > src/sdl/dview.c:12: warning: unused variable 'trow' > src/sdl/dview.c: In function 'dview_class_init': > src/sdl/dview.c:321: error: 'GConfClient' undeclared (first use in this > function) > src/sdl/dview.c:321: error: (Each undeclared identifier is reported only once > src/sdl/dview.c:321: error: for each function it appears in.) > src/sdl/dview.c:321: error: 'conf' undeclared (first use in this function) > src/sdl/dview.c:321: warning: implicit declaration of function > 'gconf_client_get_default' > src/sdl/dview.c:322: warning: ISO C90 forbids mixed declarations and code > src/sdl/dview.c:326: warning: implicit declaration of function > 'gconf_client_get_string' > src/sdl/dview.c:326: warning: assignment makes pointer from integer without a > cast > make: *** [obj/mamed/sdl/dview.o] Error 1 > make: *** Waiting for unfinished jobs.... > > !!! ERROR: games-emulation/sdlmame-0.108_p3 failed. > Call stack: > ebuild.sh, line 1539: Called dyn_compile > ebuild.sh, line 939: Called src_compile > ebuild.sh, line 1248: Called games_src_compile > games.eclass, line 136: Called die > It was the debugger bailing out. once i commented out DEBUG=1 (leaving NEW DEBUG uncommented) in the makefile it compiled succesfully.
Created attachment 96620 [details] sdlmame-0.108_p3.ebuild (In reply to comment #6) > once i commented out DEBUG=1 It's better to quote 1 line rather than 100 ;) Here's an ebuild which removes & fixes the "debug" problems. Funnily enough, I still much prefer the beautiful anti-aliasing of "xmame mrdo -ef 2 -s 3" from the xmame ebuild, over "mameat -rompath ~/games/xmame/roms -antialias -filter -video opengl mrdo.zip"
SDLMAME 0.109 released http://rbelmont.mameworld.info/sdlmame0109.zip changelog: Up to date with mainline 0.109 (see whatsnew.txt for details) Fixed Win32 builds using pure stock mamedev.org MinGW setups (RB) Added support for generic PowerPC builds (TkChris) Support on Linux, Win32, and Mac OS X for the new “trap to system debugger” functionality (RB)
Hi, nice ebuild, this works just fine with SDLMAME 0.109, on x86 - some comments: a) the sed to disable debug is no longer required b) homepage is now http://rbelmont.mameworld.info/?page_id=163 c) no need for pkg_nofetch{} b/c it will go on gentoo mirrors d) would be nice to rename binary to sdlmame instead of mameat e) OGL_PIXELBUFS is stated to be broken for now f) can you make an ebuild for sdlmess too? (or I can) Games herd: xmame/xmess is not going to release for a while/ever again, I can give evidence if you like (but please keep it around for some time.) SDLMAME/SDLMESS is the future since the big rendering rewrite circa 0.107.
(In reply to comment #9) > c) no need for pkg_nofetch{} b/c it will go on gentoo mirrors Hmm, but it isn't on gentoo mirrors yet, so it should probably be changed when it is. Or someone points out a proper way to have an ebuild pass the -U argument with a different user-agent to wget. > f) can you make an ebuild for sdlmess too? (or I can) I already have also for sdlhazemd, will clean them up and post them shortly since there is interest. The other points seemed fine, and I'll post an update in a bit.
Created attachment 100530 [details] sdlmame-0.109.ebuild
Created attachment 100533 [details] sdlmame-0.109_p3.ebuild Note that the renaming of the binary in both of these ebuilds also changes the name of the ini, in this case this might be a good idea to have one name regardless of cpu/arch. The ini should now be at ~/.mame/sdlmame.ini instead of ~/.mame/mame??.ini.
Thank you! I believe the new debugger depends upon GTK+-2.x, but haven't tested it myself. I'll report back. I found that sdlmame is writing its config directories (config, nvram, presets) to my top-level home directory, in other words not keeping things in .sdlmame or .mame. I'll try this new ebuild. What else .. oh, should restrict strip still be in there? SDLMAME froze hard when using OpenGL output with the latest open-source Radeon drivers, but that's probably the drivers, not SDLMAME. Cheers~
(In reply to comment #13) > Thank you! I believe the new debugger depends upon GTK+-2.x, but haven't tested > it myself. I'll report back. Yes, you're right, I'll post updates to reflect that dep. > I found that sdlmame is writing its config > directories (config, nvram, presets) to my top-level home directory, in other > words not keeping things in .sdlmame or .mame. I'll try this new ebuild. Well, that's true per default, you'll have to edit the ini to change that, if you do that it is also happy to use the ini itself from ~/.mame. But that's not something that the ebuild itself can do much about, to change the defaults would need source level changes. > What else .. oh, should restrict strip still be in there? > Hmm, I don't know I just tried it and I didn't get a QA Warning, and there is no stripping in the makefile, and I like my binaries stripped, so I'm assuming it's ok this way. > SDLMAME froze hard when using OpenGL output with the latest open-source Radeon > drivers, but that's probably the drivers, not SDLMAME. Cheers~ > Probably, works fine for me with nvidia.
Created attachment 100559 [details] sdlmame-0.109.ebuild
Created attachment 100560 [details] sdlmame-0.109_p3.ebuild reflect gtk+-2 dep for the debugger
Created attachment 101089 [details] sdlmame-0.109_p4.ebuild bump for 0.109u4
For the ebuild to properly finish compiling I had to add the following line: case $(get-flag march) in pentium3) enable_feature x86 PM;; pentium-m) enable_feature x86 PM;; pentium4) enable_feature x86 P4;; athlon*) enable_feature x86 ATHLON;; The linr with pentium-m and now it works. Thank you for the ebuild. Max
Created attachment 101118 [details] sdlmame-0.109_p4.ebuild Adds "tools" USE flag, and explicit emake options.
Created attachment 101244 [details] sdlmame-0.109_p5.ebuild Bump to 0.109u5 with the changes made by Paul Bredbury.
Created attachment 101772 [details] sdlmame-0.110_p1.ebuild bump version from 109_u5 to 110_u1 using the sdlmame-0.109_p5.ebuild
Created attachment 102256 [details] sdlmame-0.110_p2.ebuild bump version from 110_u1 to 110_u2 using the sdlmame-0.110_p1.ebuild
Something isn't clear.... from Pandor errorlog it seems it relies on gconf as a dependancy, but there's not that dep in the ebuild (gtk+-2 isn't depending on gconf!!)
Created attachment 102497 [details] sdlmame-0.110_p2.ebuild Added gconf to deps.
Created attachment 102523 [details] sdlmame-0.110_p2.ebuild The gconf dep is only needed by the debugger just as the gtk one.
I downloaded http://rbelmont.mameworld.info/sdlmame0110u2.zip with wget so I guess the website isn't blocking wget anymore. I guess the fetch-restriction can be removed.
(In reply to comment #26) > I guess the website isn't blocking wget anymore. It is still blocking. You probably set "user-agent" in ~/.wgetrc
Created attachment 104099 [details] sdlmame-0.111.ebuild new version fix distcc compilation add patch from wolfmame copy patches from http://wolfmame.marpirc.net/ to directory files
All of that enable_feature stuff that only changes CFLAGS isn't needed. custom-cflags USE flag can go. mirror://gentoo/${MY_P}.zip won't need the fetch restriction.
Any objection to this patch[1] as it makes it less of a pain to convert the ebuild over to git, for those who want to keep up with it's development, and the author says he'll probably want to use git in the future[2]. There may be some more adjustment to clean it up, such as moving 'target' up. Thanks. [1] --- sdlmame-0.111.ebuild 2007-01-14 20:13:58.567579113 -0800 +++ sdlmame-0.111-r1.ebuild 2007-01-14 19:53:29.506080000 -0800 @@ -53,7 +53,9 @@ epatch ${FILESDIR}/mamerand111.diff epatch ${FILESDIR}/wolf111.diff +} +src_compile() { sed -i \ -e "/PM.*=/s:^:# :" \ -e "/MIPS3_DRC.*= 1/s:^:# :" \ @@ -90,9 +92,7 @@ # use x86 && enable_feature dynarec X86_VOODOO_DRC enable_feature debug DEBUG -} -src_compile() { local target="all" use tools || target="maketree emulator" [2] http://www.bannister.org/forums/ubbthreads.php?ubb=showflat&Number=25699&page=2#Post25701
(In reply to comment #30) > less of a pain to convert the ebuild over to git How does it make it less of a pain? Just do the unpacking at the start of src_unpack, as with normal cvs and subversion ebuilds. Anyway, the convention is to have a *separate* ebuild for them, named e.g. ${PN}-9999.
(In reply to comment #31) > How does it make it less of a pain? Any repository eclass will overwrite src_unpack (obviously), src_compile is left alone by these eclass', that's why moving these things out of src_unpack is an improvement. With the patch if the user/maintainer wanted to make a -9999 ebuild in the future, all they'd have to do is inherit, remove src_unpack and add the repository variable remove the SRC_URI, removing 1 step. I'm simply lobbying for less maintenance.
(In reply to comment #32) > moving these things out of src_unpack is an improvement. Which ignores the convention that src_unpack is the *correct* place for seds and patches. It's hardly hard work to do a cut 'n' paste.
Right. Changes to the code should be done in unpack. And inheriting an eclass does *not* override anything in the ebuild *unless* it doesn't exist. The ebuild's src_unpack would still run. You would want to run the src_unpack for the eclass if you wanted to run that one. Look at the quake3 ebuilds, as they are a single set of ebuilds that detect what "type" they are and do the right thing.
I get this message. Any suggestions what to do? (Can't download it in Firefox either): # ebuild sdlmame-0.111.ebuild digest !!! games-emulation/sdlmame-0.111 has fetch restriction turned on. !!! This probably means that this ebuild's files must be downloaded !!! manually. See the comments in the ebuild for more information. * Please download http://rbelmont.mameworld.info/sdlmame0111.zip * and move it to /usr/portage/distfiles # wget http://rbelmont.mameworld.info/sdlmame0111.zip --17:57:51-- http://rbelmont.mameworld.info/sdlmame0111.zip => `sdlmame0111.zip' Resolving rbelmont.mameworld.info... 70.86.236.122 Connecting to rbelmont.mameworld.info|70.86.236.122|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://www.google.com [following] --17:57:52-- http://www.google.com/ => `index.html.8' Resolving www.google.com... 66.249.93.104, 66.249.93.147, 66.249.93.99 Connecting to www.google.com|66.249.93.104|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://www.google.nl/ [following] --17:57:52-- http://www.google.nl/ => `index.html.8' Resolving www.google.nl... 66.249.93.104, 66.249.93.147, 66.249.93.99 Reusing existing connection to www.google.com:80. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] [ <=> ] 2,845 --.--K/s 17:57:52 (220.66 KB/s) - `index.html.8' saved [2845]
(In reply to comment #35) > I get this message. Any suggestions what to do? (Can't download it in Firefox > either): .. Yeah, check the site, the author removes old versions when new ones come out. 0112 is out, he removed 0111, so just rename the ebuild and it should work fine.
Thanks for stating the obvious :). I tried to adjust the ebuild without success :(. Can you look at it and tell me what I forgot? Error message: # ebuild sdlmame-0.112.ebuild digest !!! games-emulation/sdlmame-0.111 has fetch restriction turned on. !!! This probably means that this ebuild's files must be downloaded !!! manually. See the comments in the ebuild for more information. * Please download http://rbelmont.mameworld.info/sdlmame0111.zip * and move it to /usr/portage/distfiles !!! File sdlmame0111.zip doesn't exist, can't update Manifest
Created attachment 109840 [details] Not working sdlmame-0.112.ebuild
Created attachment 109841 [details] Not working sdlmame-0.112.ebuild Who can look at it and tell me what's wrong?
Created attachment 109846 [details] sdlmame-0.112.ebuild Made pkg_nofetch idiot-proof, hopefully.
there are patches from wolfmame, but you have to unpack wolf112.zip and mamerand112.zip and convert the files from dos to unix. quick way to convert the files: perl -i -pe 's/\015\012/\012/g' wolf112.diff perl -i -pe 's/\015\012/\012/g' mamerand112.diff
> convert the files from dos to unix. Use the edos2unix command in the eutils eclass.
(In reply to comment #40) > Created an attachment (id=109846) [edit] > sdlmame-0.112.ebuild > > Made pkg_nofetch idiot-proof, hopefully. > Thanks for the ebuild Paul. Unfortunately I get the same message :(: ebuild sdlmame-0.112.ebuild digest !!! games-emulation/sdlmame-0.111 has fetch restriction turned on. !!! This probably means that this ebuild's files must be downloaded !!! manually. See the comments in the ebuild for more information. * Please download http://rbelmont.mameworld.info/sdlmame0111.zip * and move it to /usr/portage/distfiles !!! File sdlmame0111.zip doesn't exist, can't update Manifest
(In reply to comment #43) > (In reply to comment #40) > > Created an attachment (id=109846) [edit] > > sdlmame-0.112.ebuild > > > > Made pkg_nofetch idiot-proof, hopefully. > > > > Thanks for the ebuild Paul. Unfortunately I get the same message :(: > > ebuild sdlmame-0.112.ebuild digest > > !!! games-emulation/sdlmame-0.111 has fetch restriction turned on. > !!! This probably means that this ebuild's files must be downloaded > !!! manually. See the comments in the ebuild for more information. > > * Please download http://rbelmont.mameworld.info/sdlmame0111.zip > * and move it to /usr/portage/distfiles > !!! File sdlmame0111.zip doesn't exist, can't update Manifest > That ebuild is trying to tell you something. Open up your browser of choice, goto url http://rbelmont.mameworld.info/sdlmame0112.zip after downloading put this file into your distfiles directory. Then emerge sdlmame. The ebuild cannot facilitate downloading this file, so you have to do it manually.
(In reply to comment #44) > That ebuild is trying to tell you something. Open up your browser of choice, > goto url http://rbelmont.mameworld.info/sdlmame0112.zip after downloading put > this file into your distfiles directory. Then emerge sdlmame. The ebuild cannot > facilitate downloading this file, so you have to do it manually. > I understand that only the ebuild is pointing to the wrong location?!
(In reply to comment #45) > > I understand that only the ebuild is pointing to the wrong location?! > No, 0.111 is still there as well, it's just that the site is blocking wget's user agent, so you have to use something else or call wget with -U someotheruseragent to be able to download it.
Thanks Paul the new 0.112 ebuild works flawless. I only had trouble figuring out the meaning of some USEflags.
For sdlmame 0.113 you can just rename the ebuild, looks to work fine.
In 0.113 the makefile has BUILD_EXPAT and BUILD_ZLIB enabled by default. We probably want those lines commented
(In reply to comment #48) > For sdlmame 0.113 you can just rename the ebuild, looks to work fine. > with USE=tools" 0.113 fails with: install: cannot stat `file2str': No such file or directory seems in 0.113 file2str is no longer built so I removed the tool from the ebuild: for f in chdman file2str jedutil romcmp ; do becomes for f in chdman jedutil romcmp ; do and it emerges fine now
Renaming the ebuild to sdlmame-0.114 works, however it doesn't seem to work for 0.114u1 due to portage naming conventions, does anyone know how to get around this?
You'd have to edit the ebuild to change it internally to grab the right thing.
(In reply to comment #52) > You'd have to edit the ebuild to change it internally to grab the right thing. > no you don't. just rename to sdlmame-0.114_p1.ebuild
You're right. I didn't realize it still had all the bash replacement stuff at the top.
I really appreciate all this discussion and all effort put into this ebuild... and now I ask: will this (ever) get into portage (like advancemame and xmame already are)? BTW, there is also SDLMESS, which I think should also be added to portage (like xmess).
I entirely agree, especially since Xmame/mess are currently not under development (quite behind from the most recent mame release)
The current latest stable version is 0.114 which compiled fine on my adm64 system when renamed the ebuild. Please add to portage as xmame.advmame is getting obsolete...
I have changed the sdlmame to sdlmess and changed the few bits needed to make it work. Expect an ebuild and a new bug for that package. If no one has problem I can maintain it as I use this to run my old system(s)
(In reply to comment #58) > I have changed the sdlmame to sdlmess and changed the few bits needed to make > it work. Expect an ebuild and a new bug for that package. If no one has problem > I can maintain it as I use this to run my old system(s) > Like #152888? Probably just needs a bump.
Version is now at 0.116u2, anyone have an updated ebuild?
We don't have to have fetch restrictions on the ebuild, we just need to spoof the user agent: wget -U firefox http://rbelmont.mameworld.info/sdlmame0116u2.zip This will work.
(In reply to comment #61) > We don't have to have fetch restrictions on the ebuild, we just need to spoof > the user agent: > > wget -U firefox http://rbelmont.mameworld.info/sdlmame0116u2.zip > > This will work. > I've been searching for hours for a way to implement this to no avail. Somewhere it was suggested to use EXTRA_WGET variable to specify wget parameters in it. It didn't work for me. I also tried using FETCH and FETCHCOMMAND variables specifying "wget -U firefox", nothing. Tried using wget directly in the ebuild. I'm sorry I have no experience creating ebuilds.
just put mirror://gentoo/${MY_P}.zip
I've been trying to find a way to use this, also to no avail. I'm starting to believe this isn't possible, but maybe the command can be put in pkg_nofetch() so that it's easier for the users.
Just a suggestion to get around the "<majorversion>u<minorversion>" problem: Just include the upstream stable version for now, for inclusion into Portage. Worry about the unstable version later. Are there any suggestions from more seasoned devs on what needs to be fixed before this package can be included in Portage?
Just a test report here - works great for me on x86.
I tried to adapt Paul's ebuild for sdlmame 0.117 but I get this error: >>> Source compiled. >>> Test phase [not enabled]: games-emulation/sdlmame-0.117 >>> Install sdlmame-0.117 into /var/tmp/portage/games-emulation/sdlmame-0.117/image/ category games-emulation !!! dobin: sdlmame does not exist !!! ERROR: games-emulation/sdlmame-0.117 failed. Call stack: ebuild.sh, line 1621: Called dyn_install ebuild.sh, line 1067: Called qa_call 'src_install' ebuild.sh, line 44: Called src_install sdlmame-0.117.ebuild, line 109: Called die !!! dogamesbin sdlmame failed !!! If you need support, post the topmost build error, and the call stack if relevant. !!! A complete build log is located at '/var/tmp/portage/games-emulation/sdlmame-0.117/temp/build.log'. !!! This ebuild is from an overlay: '/usr/local/portage'
Created attachment 124822 [details] sdlmame-0.117
Comment on attachment 124822 [details] sdlmame-0.117 Only changed the name.
(In reply to comment #67) > I tried to adapt Paul's ebuild for sdlmame 0.117 but I get this error: > > >>> Source compiled. > >>> Test phase [not enabled]: games-emulation/sdlmame-0.117 > > >>> Install sdlmame-0.117 into /var/tmp/portage/games-emulation/sdlmame-0.117/image/ category games-emulation > !!! dobin: sdlmame does not exist > > !!! ERROR: games-emulation/sdlmame-0.117 failed. > Call stack: > ebuild.sh, line 1621: Called dyn_install > ebuild.sh, line 1067: Called qa_call 'src_install' > ebuild.sh, line 44: Called src_install > sdlmame-0.117.ebuild, line 109: Called die > > !!! dogamesbin sdlmame failed > !!! If you need support, post the topmost build error, and the call stack if > relevant. > !!! A complete build log is located at > '/var/tmp/portage/games-emulation/sdlmame-0.117/temp/build.log'. > > !!! This ebuild is from an overlay: '/usr/local/portage' > the problem is this line in the makefile: makefile:240:FULLNAME = $(PREFIX)$(NAME)$(SUFFIX) the binary name is ${PN}+ a suffix that indicates the build arch or if it's debug, suffixes can be: pp, pm, p4, at, 64, g4, g5, cbd, and d so what's the best approach removing SUFFIX in the makefile so that the name is always ${PN}, or adjusting the ebuild to use something like dogamesbin ${PN}${SUFFIX}
Created attachment 124986 [details] sdlmame-0.117.ebuild Fixes SUFFIX.
The commented line #29 in attachment #124221 [details] includes the "then" word belonging to the if statement, thus breaking the ebuild. Easily fixed, of course. Thanks for your work, by the way.
I suspect I'm stupid. My comment about the if statement was meant to be posted in the qmc2 bug file. Sorry.
................. Compiling src/mame/drivers/seta.c... ............ `sdl-config --cflags` -I/usr/X11/include -I/usr/X11R6/include -I/usr/openwin/include -c src/mame/drivers/seta.c -o obj/sdl/sdlmame/mame/drivers/seta.o cc1: warnings being treated as errors src/mame/video/n64.c: In function ‘render_spans_16’: src/mame/video/n64.c:2165: warning: ‘t2.r’ may be used uninitialized in this function src/mame/video/n64.c:2165: warning: ‘t2.g’ may be used uninitialized in this function src/mame/video/n64.c:2165: warning: ‘t2.b’ may be used uninitialized in this function src/mame/video/n64.c:2165: warning: ‘t2.a’ may be used uninitialized in this function src/mame/video/n64.c:2165: warning: ‘t1.r’ may be used uninitialized in this function src/mame/video/n64.c:2165: warning: ‘t1.g’ may be used uninitialized in this function src/mame/video/n64.c:2165: warning: ‘t1.b’ may be used uninitialized in this function src/mame/video/n64.c:2165: warning: ‘t1.a’ may be used uninitialized in this function src/mame/video/n64.c:2165: warning: ‘t0.r’ may be used uninitialized in this function src/mame/video/n64.c:2165: warning: ‘t0.g’ may be used uninitialized in this function src/mame/video/n64.c:2165: warning: ‘t0.b’ may be used uninitialized in this function src/mame/video/n64.c:2165: warning: ‘t0.a’ may be used uninitialized in this function make: *** [obj/sdl/sdlmame/mame/video/n64.o] Error 1 make: *** Waiting for unfinished jobs.... * * ERROR: games-emulation/sdlmame-0.117 failed. * Call stack: * ebuild.sh, line 1647: Called dyn_compile * ebuild.sh, line 988: Called qa_call 'src_compile' * ebuild.sh, line 44: Called src_compile * sdlmame-0.117.ebuild, line 105: Called die * * emake failed * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/games-emulation/sdlmame-0.117/temp/build.log'.
zhoumi: This happen when you try to compile with GCC 4.2.x, this compiler is not supported yet for SDLMAME.
(In reply to comment #75) > zhoumi: This happen when you try to compile with GCC 4.2.x, this compiler is > not supported yet for SDLMAME. > sdlmame-0.117 compiles with no problem for me with gcc-4.2.0 on amd64.
On amd64 those warnings are not errors anymore, thus you can compile SDLMAME with GCC 4.2.0.
I use the following src_unpack which not only handles automatically downloading sdlmame, but also applies a patch to set the configuration files to a more sane place ($HOME/.mame/ instead of the current directory). src_unpack() { local zip zip=${PN}$(echo ${PV} | sed -r -e "s/\.([0-9]+)$/.u\1/" -e "s/\.//g").zip # his domain blocks calls without a UserAgent (which is wget's default) addwrite ${DISTDIR}/sdlmame mkdir -p ${DISTDIR}/sdlmame pushd >/dev/null ${DISTDIR}/sdlmame local zipDir=${zip%.zip} rm -rf ${zipDir} if [ -e "$zip" ] ; then # we can't test for the file's existence, must find out why unzip $zip || \ curl -A Firefox -C - http://rbelmont.mameworld.info/$zip -o $zip unzip $zip else curl -A Firefox -C - http://rbelmont.mameworld.info/$zip -o $zip unzip $zip fi rm $zip mv ${zipDir} ${WORKDIR}/${P} popd epatch "${FILESDIR}/sdlmame_path.patch" }
Created attachment 128316 [details, diff] a patch against sldmame to put the configuration files in a more sane place
Maybe, instead of ~/.mame, the better would be ~/.sdlmame (like xmame stores at ~/.xmame). Also, try to submit this patch to sdlmame author.
This patch won't be accepted as there no /usr/ or $HOME on Windows or OS/2 etc.
(In reply to comment #81) > This patch won't be accepted as there no /usr/ or $HOME on Windows or OS/2 etc. > Not into the main sdlmame, but I could solve that by wrapping the directory names in os dependant preprocessor tokens. Even though I doubt it would be accepted to break with mame tradition from so long, but who knows. Good enough to be accepted by this build I think.
(In reply to comment #49) > In 0.113 the makefile has BUILD_EXPAT and BUILD_ZLIB enabled by default. We > probably want those lines commented I haven't tried the ebuild, but reading SDLMAME.txt and reading the ebuild, I agree with Joao Rodrigues. These should be commented, sdlmame should build using system expat and zlib.
Created attachment 131628 [details] sdlmame-0.119.ebuild New sdlmame (0.119). Changes: - Version bump; - Applying wolfmame patches (they must be in $(FILESDIR)/0.119); - Disabled embedded expat and zlib; - SRC_URI is set to look for the file on a gentto mirror. For now, download the file manually and put it in the distfiles directory; - Cleanup: Removed some USE flags from the older ebuilds. Also, I find the ebuild is cleaner to read now. I would appreciate some feedback, mainly from an amd64 user. PPC support is disabled (I would like to know if someone is willing to help :) ).
Created attachment 131632 [details] Wolfmame patches for sdlmame-0.119 Wolfmame patches for sdlmame-0.119.ebuild.
Created attachment 131877 [details, diff] Patch to allow the compilation on PPC systems After applying this patch to the ebuild, I could finally compile SDLMAME on my PPC machine. I'm not sure if this works for PPC64 users or not. I guess we can add a ~ppc keyword now. :-)
Created attachment 133231 [details] sdlmame-0.119_p3.ebuild Minor sdlmame release (0.119u3) Ebuild changes: - Disable wolfmame patches (apply cleanly but don't compile) - Better arch/cpu detection - Add ~ppc (thanks Henrique)
The ebuild for the new release (0.119u4) is in the sunrise overlay. You can find it at: http://overlays.gentoo.org/svn/proj/sunrise/reviewed/games-emulation/sdlmame/
Version bump (0.120a). New ebuild in sunrise. http://overlays.gentoo.org/svn/proj/sunrise/reviewed/games-emulation/sdlmame/
(In reply to comment #89) > Version bump (0.120a). New ebuild in sunrise. > > http://overlays.gentoo.org/svn/proj/sunrise/reviewed/games-emulation/sdlmame/ > when using the "minimal" use flag emerge fails with Compiling src/lib/util/xmlfile.c... Compiling src/version.c... make: *** No rule to make target `obj/sdl/sdlmame/mame/machine/6821pia.o', needed by `sdlmame'. Stop.
(In reply to comment #90) > when using the "minimal" use flag emerge fails with (...) Upstream bug. Some files were moved but the tiny makefile wasn't updated. It's a simple fix. I'm going to try to push the change upstream. Do you have any reason to use the "minimal" flag? I'm thinking about removing it. It only builds a small set of drivers and doesn't seem useful at all.
(In reply to comment #91) > (In reply to comment #90) > > when using the "minimal" use flag emerge fails with (...) > > Upstream bug. Some files were moved but the tiny makefile wasn't updated. It's > a simple fix. I'm going to try to push the change upstream. > > Do you have any reason to use the "minimal" flag? I'm thinking about removing > it. It only builds a small set of drivers and doesn't seem useful at all. > no special reason just testing the ebuild
Created attachment 137353 [details] build for sdlmame 0.121 This is an ebuild for sdlmame 0.121
Created attachment 137358 [details] ebuilds and all related files for sdlmame 0.121 and 0.121u1 i like these
Needs to list curl and unzip in it's dependencies
(In reply to comment #95) > Needs to list curl and unzip in it's dependencies Actually, that curl trick can also be done with wget. Both of the following lines are equivalent: curl -A Firefox -C - http://rbelmont.mameworld.info/$zip -o $zip wget -U Firefox -c http://rbelmont.mameworld.info/$zip -O $zip
1) Sorry for my english 2) There are hardcoded path in src/osd/sdl/sdlmain.c that point to "$HOME/.mess" and "$HOME/.mame" for the "inipath" settings that must be correct.
Just wanted to make you aware that 0.122 has been out for some days. Thanks for your hard work!
Created attachment 141808 [details] sdlmame 0.122.7 ebuild. Use files from my last uploaded ebuild Yep
You need to update the architecture specific optimizations. The makefile options ATHLON=1 P4=1 etc. have been replaced by ARCHOPS=<whatever gcc option you want>, for example ARCHOPS=-march=athlon-xp.
(In reply to comment #29) > mirror://gentoo/${MY_P}.zip won't need the fetch restriction. (In reply to comment #63) > just put mirror://gentoo/${MY_P}.zip
(In reply to comment #99) > Created an attachment (id=141808) [edit] > sdlmame 0.122.7 ebuild. Use files from my last uploaded ebuild Instructions for getting new SDLMAME version 0.123 emerged: I used James' attachment sdlmame-0.122.7.ebuild but just renamed it to sdlmame-0.123.ebuild. Then I downloaded sdlmame-0.121-and-0.121.1-files.tar.gz (also from James) and untarred it into /usr/local/portage/games-emulation/sdlmame/ (where sdlmame-0.122.7.ebuild and sdlmame-0.123.ebuild live). Then, as root run 'ebuild /usr/local/portage/games-emulation/sdlmame/sdlmame-0.123.ebuild digest'. Then 'emerge sldmame'. This Works For Me. I got Red Baron running OK, except controlling the plane with the arrow keys doesn't work just right -- the plane ends up in a continuous bank to the right. This might have something to do with built-in autocalibration of the joystick device(?). Guess I need to break out the old joystick....
(In reply to comment #102) > Then, as root run 'ebuild > /usr/local/portage/games-emulation/sdlmame/sdlmame-0.123.ebuild digest'. Then > 'emerge sldmame'. This Works For Me. Sorry, that should have been 'emerge sdlmame' -- been making that same typo all morning :^(
(In reply to comment #102) > (In reply to comment #99) > > Created an attachment (id=141808) [edit] > > sdlmame 0.122.7 ebuild. Use files from my last uploaded ebuild > > Instructions for getting new SDLMAME version 0.123 emerged: > > I used James' attachment sdlmame-0.122.7.ebuild but just renamed it to > sdlmame-0.123.ebuild. Then I downloaded sdlmame-0.121-and-0.121.1-files.tar.gz > (also from James) and untarred it into > /usr/local/portage/games-emulation/sdlmame/ (where sdlmame-0.122.7.ebuild and > sdlmame-0.123.ebuild live). > > Then, as root run 'ebuild > /usr/local/portage/games-emulation/sdlmame/sdlmame-0.123.ebuild digest'. Then > 'emerge sldmame'. This Works For Me. > > I got Red Baron running OK, except controlling the plane with the arrow keys > doesn't work just right -- the plane ends up in a continuous bank to the right. > This might have something to do with built-in autocalibration of the joystick > device(?). Guess I need to break out the old joystick.... > Same for 0.124 version.
I spent some time on an ebuild which is hopefully clean enough to be included in the main portage tree. It's based on the ebuilds here but most parts are re-written, so thanks to everyone who wrote one of the previous ebuilds here. The files are available here (too lazy to add every single file here): http://dev.gentoo.org/~joker/sdlmame/ Distfiles are currently located there too (copy to /usr/portage/distfiles). I wont use all this rather nasty "User-Agent" fake functions for fetching but simply mirror the distfiles. I know it works, but i prefer it as clean as possible. * Some (new) ebuild features are: - Hopefully usable config search paths ($HOME/.sdlmame, /etc/sdlmame) - Installs initial and config files with sane search paths - Installs additional data files (nice UI font, locale keymap files) - No patches and as few "sed"-pain as possible - Updated dependencies (Xinerama is needed etc., I forgot something for sure) - No stripping of binaries at build time. (no more RESTRICT=strip needed) - Uses make.conf CFLAGS and filters hardcoded ones (-Ox and -pipe) - Has USE=opengl (not really tested without opengl) - wolfmame patches removed (sorry, but i couldn't find recent ones and such things usually block updates to newer versions) - Creates default directories (roms, artworks, samples, ctrlr) - Removed most "ARCH" features since they got removed in the makefile * Possible flaws: - Probably lots of small glitches and ebuild nah-nahs. It's the first attempt and such a complex ebuild usualy has some minor issues at the beginning. - Only tested on amd64. I kept the x86 and ppc keyword though - If ppc64 would work maybe it needs the "enable_feature PTR64" as well. Same for possible other 64bit ARCHs I'll commit as soon as i get an "OK" from the games people. Don't worry i also plan to fix the reported bugs later ;)
To explain the "u" releases. I don't plan to track the "u" releases in general. This one is a special case because 0.124 has broken "joymap" support, which is needed to configure the order of the joysticks.
(In reply to comment #105) > - Only tested on amd64. I kept the x86 and ppc keyword though Your ebuild looks really nice, but in order to work on ppc you have to add the following in src_compile: if use ppc; then einfo "Enabling PPC support" enable_feature BIGENDIAN disable_feature X86_MIPS3_DRC disable_feature X86_PPC_DRC fi I've tested it with this modification and it works now.
(In reply to comment #105) > I spent some time on an ebuild which is hopefully clean enough to be included > in the main portage tree. It's based on the ebuilds here but most parts are > re-written, so thanks to everyone who wrote one of the previous ebuilds here. > > The files are available here (too lazy to add every single file here): > > http://dev.gentoo.org/~joker/sdlmame/ > > > Distfiles are currently located there too (copy to /usr/portage/distfiles). I > wont use all this rather nasty "User-Agent" fake functions for fetching but > simply mirror the distfiles. I know it works, but i prefer it as clean as > possible. > > * Some (new) ebuild features are: > > - Hopefully usable config search paths ($HOME/.sdlmame, /etc/sdlmame) > - Installs initial and config files with sane search paths > - Installs additional data files (nice UI font, locale keymap files) > - No patches and as few "sed"-pain as possible > - Updated dependencies (Xinerama is needed etc., I forgot something for sure) > - No stripping of binaries at build time. (no more RESTRICT=strip needed) > - Uses make.conf CFLAGS and filters hardcoded ones (-Ox and -pipe) > - Has USE=opengl (not really tested without opengl) > - wolfmame patches removed (sorry, but i couldn't find recent ones and such > things usually block updates to newer versions) > - Creates default directories (roms, artworks, samples, ctrlr) > - Removed most "ARCH" features since they got removed in the makefile > > * Possible flaws: > > - Probably lots of small glitches and ebuild nah-nahs. It's the first attempt > and such a complex ebuild usualy has some minor issues at the beginning. > - Only tested on amd64. I kept the x86 and ppc keyword though > - If ppc64 would work maybe it needs the "enable_feature PTR64" as well. Same > for possible other 64bit ARCHs > > > I'll commit as soon as i get an "OK" from the games people. Don't worry i > also plan to fix the reported bugs later ;) > Looks good. Does the -DINI_PATH thing work (I was doing what I assume this does before with my paths prefix only it was probably a bit more sophisticated)? One thing I'd do though is replace your if use amd64 blah blah else stuff with the case statement I used in my ebuild. This allows it to work on x86. Something like this: case ${ARCH} in amd64) einfo "Enabling 64-bit support" enable_feature PTR64 enable_feature AMD64 ;; x86) einfo "Optimizing build for $(get-flag march)" case $(get-flag march) in pentium3) enable_feature PM;; pentium-m) enable_feature PM;; pentium4) enable_feature P4;; athlon) enable_feature ATHLON;; k7) enable_feature ATHLON;; i686) enable_feature I686;; pentiumpro) enable_feature I686;; esac ;; ppc) einfo "Enabling PPC support" enable_feature BIGENDIAN disable_feature X86_MIPS3_DRC disable_feature X86_PPC_DRC ;; esac Also for now I think it's good to have the fake downloading with wget until sdlmame is put in the gentoo mirror. I'll hack our versions together and put it into my layman repository. Much easier for people to access through a portage overlay.. I'll give you svn write access to my overlay if you want?
(In reply to comment #105) > Distfiles are currently located there too (copy to /usr/portage/distfiles). I > wont use all this rather nasty "User-Agent" fake functions for fetching but > simply mirror the distfiles. I know it works, but i prefer it as clean as > possible. Ah sorry didn't notice this comment. It isn't too nasty, I mean it's only a few lines of script and it makes the ebuild work straight out of the overlay. I'd think it's better to have a working ebuild that anyone can use as it's easy to remove the top of the src_unpack function to "clean it up" once the sdlmame package becomes mirrored.
(In reply to comment #107) > (In reply to comment #105) > > - Only tested on amd64. I kept the x86 and ppc keyword though > > Your ebuild looks really nice, but in order to work on ppc you have to add the > following in src_compile: > > if use ppc; then > einfo "Enabling PPC support" > enable_feature BIGENDIAN > disable_feature X86_MIPS3_DRC > disable_feature X86_PPC_DRC > fi I'm sorry, i was wrong in my previous comment. To enable PPC support you just have to enable BIGENDIAN. You don't have to disable X86_MIPS3_DRC or X86_PPC_DRC. At leats that's what my tests tell me. So, to enable PPC support, you would have to use: if use ppc; then einfo "Enabling PPC support" enable_feature BIGENDIAN fi
(In reply to comment #108) > One thing I'd do though is replace your if use amd64 blah blah else stuff with > the case statement I used in my ebuild. This allows it to work on x86. > Something like this: > > case ${ARCH} in > amd64) > einfo "Enabling 64-bit support" > enable_feature PTR64 > enable_feature AMD64 > ;; > x86) > einfo "Optimizing build for $(get-flag march)" > case $(get-flag march) in > pentium3) enable_feature PM;; > pentium-m) enable_feature PM;; > pentium4) enable_feature P4;; > athlon) enable_feature ATHLON;; > k7) enable_feature ATHLON;; > i686) enable_feature I686;; > pentiumpro) enable_feature I686;; > esac > ;; > ppc) > einfo "Enabling PPC support" > enable_feature BIGENDIAN > disable_feature X86_MIPS3_DRC > disable_feature X86_PPC_DRC > ;; > esac Those "ATHLON", "AMD64", "P4" makefile options don't exist anymore. They have been replaced by one option called ARCHOPTS, which take gcc options. You can put stuff like "-march athlon-xp" in there for example. In addition, for the debug build you need to enable DEBUGGER=1 to build the debugger.
Sorry, but i and people from the games herd agreed that this fetch hack is too ugly. Once the ebuild is added to the maintree and the distfiles located on the gentoo mirrors, it automaticaly gets fetched from the mirrors. No loss for the user. I know some people do local bumps to get the newer versions faster, but that wont make me break almost every ebuild rule and guideline. In fact, with that fetch hack, the ebuild would never be part of the gentoo mainline and always be either a bugzilla only thing or something for a 3rd party overlay. The "until it gets added to the portage tree" is a matter of days since i'll be doing it myself ;) I'll add the DEBUGGER based on USE to the make_opts and add the ppc stuff and then commit it later this week or so.
Ok, i reuploaded the ebuilds with the DEBUGGER and the "if use ppc" part. I kept it simple, so the 64bit or big-endian mode can be expanded with "||" (or) tests for other archs. If there are more archs with own settings i'll use a "case" func like in the previous ebuilds.
Shouldn't this bug be closed, now that SDLMame in Portage?
Yes, i just wanted to give it a few days to settle down and check for possible comments, complains or regressions. * Closing now * A big thank-you to everyone who wrote and updated the ebuilds and patches attached to this bug during the last (almost) 2 years!
