Date: Mon, 30 Oct 2023 00:08:00 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 274783] emulators/mame: Update to 0.260 Message-ID: <bug-274783-7788-kCTdttcROS@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-274783-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-274783-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D274783 --- Comment #3 from Alastair Hogge <agh@riseup.net> --- (In reply to Daniel Engberg from comment #2) Hi Daniel, >Is it possible to also drop redundant system libs in 3rdparty dir? https://src.fedoraproject.org/rpms/mame/blob/rawhide/f/mame.spec#_148 Oh are you suggesting adding the bundled libs we do not use on FreeBSD to ${EXTRACT_AFTER_ARGS}? Seems like a great idea, I will see what I can do. > Shouldn't PROFILER=3D0 SYMBOLS=3D0 MAKE_ENV's be added to non DEBUG build= s? Originally, I think I left out setting anything that was already the defaul= t in the MAME makefile, tho, there might be one or two cases that do not follow that. Do you think, or is it recommended practice to explicitly set the inv= erse of what is currently set in the Port Makefile? > Is there a reason why we don't have OPENMP enabled? > We also seem to lack nasm looking at other repos, not needed? I have not noticed any of the Port tools reporting any deficits here. I had never thought to see what Fedora does, in the past, I think I referred to A= rch, Gentoo, MSYS2/MinGW, Net and OpenBSD. Tho the Fedora package looks to inclu= de an interesting patch: https://src.fedoraproject.org/rpms/mame/blob/rawhide/f/0001-Hack-allowing-b= gfx-to-initialise-in-absence-of-dx9-s.patch that I will definitely test here. > OPTIMIZE=3D0 should always be set, let our framework handle optimization Maybe it is too early for me, but I am confused here. We currently set OPTI= MIZE based on whether option DEBUG is set or not, should it only be set to 0, and the logic for the inverse should be removed? I do not recall the Ports framework handling building MAME with debug correctly, that could be the re= ason for the current DEBUG_MAKE_ENV_fu in the Makefile. > Initial compile of lua(?) right at the beginning overrides framework, ...= "-Wall -Wextra -Os" The whole Lua thing in MAME is a mess, on top of the mess that is bundling external libraries. I vaguely recall removing that step, and getting the bu= ild to use system Lua, however I do not think I was successful, because the ste= p is still there, and what little hair I had left was now on the floor. MAME has also moved to a C++ build of Lua, so the Lua scripting engine can unwind the stack. My plan was to eventually look at adding a Lua Port or Flavor based = on the Arch Lua C++ package, then move MAME to use the external Lua library be= fore addressing Lua again. > For whatever reason VERBOSE toggle don't seem to work or at least it does= n't get passed to scripts/genie.lua. Yes this is a real pain point, or source of a great many stressors, and GEN= ie is hostile to Net, and OpenBSD. There was a upstream pull request to convert MAME to CMake, the OP eventually closed the ticket, due to a perceived lack= of interest from the project. My aim, seeing as MAME is strictly an Apple/Linux/Microsoft show, was to resurrect the pull request, build and te= st locally on FreeBSD using the Linuxulator, and MinGW-64 (I have no access to= any Apple system), and hopefully work with MAME to convert to a build system th= at does not have the foibles that GENie does, but that is going to be very challenging....very....extremely to say the least. MAME is well aware of the shortcomings of GENie too. I spent days many months ago trying to get GENie= to rerun, or was it, regenerate scripts/genie.lua? I cannot recall, I know I failed. GENie is a wild monster. I will have a look again. > That being said, I can't get the genie script to accept that option eithe= r by forcing it from Mame's makefile but I didn't look too closely at it (u= nknown/invalid option). Sounds like GENie. It is a mess. > Worst case you can just force it by removing the if statement. https://gi= thub.com/mamedev/mame/blob/mame0260/scripts/genie.lua#L760 This should be b= y default though as we want useful logs. OK, thanks will add that. > Several distros pulls in ASIO as a system lib, possible in our case? Will look at ASIO again. Note, that Alpine does not build with system ASIO either. > Possibly import https://git.alpinelinux.org/aports/tree/testing/mame/nona= g.patch ? No idea what the aim of this patch is, but if it builds and runs, sure it c= an be included. > They also pull in https://git.alpinelinux.org/aports/tree/testing/mame/AP= KBUILD#n51 which might be of interest? How do I view that actual patch? The commit message referencing that patch = does not clearly state why it is needed or wanted: https://git.alpinelinux.org/aports/commit/testing/mame?id=3Da215b231b08173e= b8adcb059040c7f21b38f26cf I also want to the get the separate ${TARGET} zexall for the Z80 emulation going too, but that fails to build with many C++ scoping violations, if I recall correctly. Thanks for the feedback. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-274783-7788-kCTdttcROS>