Created attachment 245963 [details] Update to 0.260 and do some Makefile house keeping * Update to 0.260 * make use of ${EXTRACT_AFTER_ARGS} for a number of files/dirs that are not required for MAME on FreeBSD, this removes some post-patch work from the Makefile * Avoid extracting bgfx shaders for proprietary systems * Avoid extracting the man page for ldplayer, as it is not built * Update option TOOLS description * Increase the default amount of information produced when built with DEBUG * Drop the conditional logic for powerpc, and use LLVM-16 for all FreeBSD-14+ builds * Move some NLS logic deleting .po files to ${COPYTREE_SHARE}, and simple exclude copying those files to ${STAGEDIR}. This was originally in the wrong Makefile target, port-build * Add two more MAME ${SUBTARGETS} as tools; mamevirtual provides similar ldplayer functionality thru the MAME GUI * Remove hard-coded names from do-install-TOOLS-on Makefile target * Remove local upstream patches that were required to build 0.259
Forgot to remark: 12.4-{amd64,i386} poudriere-testport OK 13.2-{amd64,i386} poudriere-testport OK 14.rc2-{amd64,i386} poudriere-testport OK 15-{amd64,i386} poudriere-testport OK
Hi, I have a few questions that might be worth looking into to further improve the port. Is it possible to also drop redundant system libs in 3rdparty dir? https://src.fedoraproject.org/rpms/mame/blob/rawhide/f/mame.spec#_148 Shouldn't PROFILER=0 SYMBOLS=0 MAKE_ENV's be added to non DEBUG builds? Is there a reason why we don't have OPENMP enabled? We also seem to lack nasm looking at other repos, not needed? OPTIMIZE=0 should always be set, let our framework handle optimization Initial compile of lua(?) right at the beginning overrides framework, ... "-Wall -Wextra -Os" For whatever reason VERBOSE toggle don't seem to work or at least it doesn't get passed to scripts/genie.lua. That being said, I can't get the genie script to accept that option either by forcing it from Mame's makefile but I didn't look too closely at it (unknown/invalid option). Worst case you can just force it by removing the if statement. https://github.com/mamedev/mame/blob/mame0260/scripts/genie.lua#L760 This should be by default though as we want useful logs. Several distros pulls in ASIO as a system lib, possible in our case? Possibly import https://git.alpinelinux.org/aports/tree/testing/mame/nonag.patch ? They also pull in https://git.alpinelinux.org/aports/tree/testing/mame/APKBUILD#n51 which might be of interest? Thanks for contributing! Best regards, Daniel
(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=0 SYMBOLS=0 MAKE_ENV's be added to non DEBUG builds? Originally, I think I left out setting anything that was already the default 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 inverse 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 Arch, Gentoo, MSYS2/MinGW, Net and OpenBSD. Tho the Fedora package looks to include an interesting patch: https://src.fedoraproject.org/rpms/mame/blob/rawhide/f/0001-Hack-allowing-bgfx-to-initialise-in-absence-of-dx9-s.patch that I will definitely test here. > OPTIMIZE=0 should always be set, let our framework handle optimization Maybe it is too early for me, but I am confused here. We currently set OPTIMIZE 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 reason 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 build to use system Lua, however I do not think I was successful, because the step 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 before addressing Lua again. > For whatever reason VERBOSE toggle don't seem to work or at least it doesn't get passed to scripts/genie.lua. Yes this is a real pain point, or source of a great many stressors, and GENie 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 test 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 that 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 either by forcing it from Mame's makefile but I didn't look too closely at it (unknown/invalid option). Sounds like GENie. It is a mess. > Worst case you can just force it by removing the if statement. https://github.com/mamedev/mame/blob/mame0260/scripts/genie.lua#L760 This should be by 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/nonag.patch ? No idea what the aim of this patch is, but if it builds and runs, sure it can be included. > They also pull in https://git.alpinelinux.org/aports/tree/testing/mame/APKBUILD#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=a215b231b08173eb8adcb059040c7f21b38f26cf 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.
Comment on attachment 245963 [details] Update to 0.260 and do some Makefile house keeping Will work on an updated patch.
Hi, I got the impression by having a quick look that PROFILER=0 amd SYMBOLS=0 might not be implied being undefined but as you said, GENie seems to be an interesting beast. Looking back OpenMP support on other archs than i386 + amd64 wasn't very solid so many ports ended up disabling but now we have solid support and it usually gives you better performance overall. nasm seems to be a stray dependency, 0.259's source code don't mention it at all except for a few 3rdparty libs. Sorry for the noise! I think you can leave Lua alone as it isn't used for anything performance demanding, normally we default to -O2. Unless I misread the logs it looked like OPTIMIZE=0 didn't define -O at all? If we assume I didn't misread the build log we don't override the framework without a good reason and that is usually done by a toggle. https://cgit.freebsd.org/ports/tree/Mk/bsd.options.desc.mk#n396 https://docs.freebsd.org/en/books/porters-handbook/book/#dads-cflags To be honest, I assumed that nonag removed this screen ( https://imgur.com/AMEyCLY) without looking more closely at it. It's been a while since I last used MAME :/ About the patch, http://forum.arcadecontrols.com/index.php/topic,164449.0.html https://github.com/antonioginer/GroovyMAME/releases/ Again, thanks for looking into this! Best regards, Daniel
(In reply to Daniel Engberg from comment #5) Hello 👋️ OK, I have fixed some things in the Makefile, but the GENie work is massive, some of my memories are starting to come back, I suspect I pushed them to the deeper, darker, forbidden recesses of my brain where they belong. MAME comes with a pre-configured, bundled GENie for FreeBSD, that is why the initial phase of the MAME build ignores most of the state from the Ports framework. The current patches files/patch-3rdparty_genie* are a result of my previous attempt to remove the patching from the port Makefile into static patches, and attempting at using the Ports to configure the pre-GENie state required to run. I left the static patches in case this work was to be investigated again. From memory, I was never able to get GENie to regenerate, or re-read the build config, and regenerate the build state, or maybe I did, but the resulting build failed. GENie is a premake successor from memory, it is not a build/make tool, but a pre-make-phase tool for parsing and generating source dependencies; by contemporary standards, it does a poor job at this now, and it is a major point of pain for package maintainers, and Users tracking MAME-main and building from source. GENie is not deterministic at all, it can, and does generate dependency order problems, and during a parallel build, some source files are incorrectly built out-of-order, and the build fails. One such common problem has now been addressed, but it is a hack to get around GENie—initially MAME was against adding hacks around GENie, but it looks like this one tipped the scales on that stance. That particular build order issue has been plaguing me for many many months now. One month, I could build with 32 threads directly on my host, and then poudriere-testport could only use 1 thread, the next month, or week, it was the other way around—I would have to use 1 thread directly on my host, but then moving to poudriere I could use all threads. That should be fixed, but the underlying problem is still there, and will resurface again under other conditions. I will have a look at GENie again, but after losing most off yesterday to it, and trying to reduce file I/O some more in the Makefile, I am not sure if that GENie work, if it comes to fruition, will make it for this update, I have other priorities. > I got the impression by having a quick look that PROFILER=0 amd SYMBOLS=0 might not be implied being undefined but as you said I have added the inverse of all the MAKE_ENV and related foo, at least to be explicit about the intention. I will compare build logs again. > Looking back OpenMP support on other archs than i386 + amd64 wasn't very solid so many ports ended up disabling but now we have solid support and it usually gives you better performance overall. I will add an OpenMP OPTION, even on my AMD Ryzen 9 3950X, MAME brings the system to it's knees sometimes, so more performance anywhere is welcome. > nasm seems to be a stray dependency, 0.259's source code don't mention it at all except for a few 3rdparty libs. Sorry for the noise! For 0.260, my grep-fu returns: $ grep -rn nasm > ./hash/cpc_cass.xml:40985: <software name="zenasm" supported="no"> >./3rdparty/genie/src/host/scripts.c:490: "erincludedirs), tool.getsystemincludedirs(cfg.systemincludedirs))),\ncppflags = ninja.list(tool.getcppflags(cfg)),\nasmflags = ninja.list(table.join(tool.getcflags(cfg), cfg.buildoptions, cfg.buildoptions_asm)),\ncflags = ninja.list(table.join(tool.getcflags(cfg), cfg.buildoptions, cfg.buildoptions_c)),\ncxxflags = ninja.list(table.join(tool.getcflags(cfg), tool.getcxxflags(cfg), cfg.buildoptions, cfg.buildoptions_cpp)),\nobjcflags = ninja.list(table.join(tool.getcflags(cfg), tool.getcxxflags(cfg), cfg.buildoptions, cfg.buildoptions_objc)),\n}\n_p(\"\")\n_p(\"# core rules for \" .. cfg.name)\n_p(\"rule cc\")\n_p(\" command = \" .. wrap_ninja_cmd(tool.cc .. \" $defines $includes $flags -MMD -MF $out.d -c -o $out $in\"))\n_p(\" description = cc $out\")\n_p(\" depfile = $out.d\")\n_p(\" deps = gcc\")\n_p(\"\")\n_p(\"rule cxx\")\n_p(\" command = \" .. wrap_ninja_cmd(tool.cxx .. \" $defines $includes $flags -MMD -MF $out.d -c -o $out $in\"))\n_p(\" description = cxx $out\")\n_p(\" de" > ./3rdparty/genie/src/host/scripts.c.orig:490: "erincludedirs), tool.getsystemincludedirs(cfg.systemincludedirs))),\ncppflags = ninja.list(tool.getcppflags(cfg)),\nasmflags = ninja.list(table.join(tool.getcflags(cfg), cfg.buildoptions, cfg.buildoptions_asm)),\ncflags = ninja.list(table.join(tool.getcflags(cfg), cfg.buildoptions, cfg.buildoptions_c)),\ncxxflags = ninja.list(table.join(tool.getcflags(cfg), tool.getcxxflags(cfg), cfg.buildoptions, cfg.buildoptions_cpp)),\nobjcflags = ninja.list(table.join(tool.getcflags(cfg), tool.getcxxflags(cfg), cfg.buildoptions, cfg.buildoptions_objc)),\n}\n_p(\"\")\n_p(\"# core rules for \" .. cfg.name)\n_p(\"rule cc\")\n_p(\" command = \" .. wrap_ninja_cmd(tool.cc .. \" $defines $includes $flags -MMD -MF $out.d -c -o $out $in\"))\n_p(\" description = cc $out\")\n_p(\" depfile = $out.d\")\n_p(\" deps = gcc\")\n_p(\"\")\n_p(\"rule cxx\")\n_p(\" command = \" .. wrap_ninja_cmd(tool.cxx .. \" $defines $includes $flags -MMD -MF $out.d -c -o $out $in\"))\n_p(\" description = cxx $out\")\n_p(\" de" The lines of interest are related to my best mate GENie :-D > I think you can leave Lua alone as it isn't used for anything performance demanding, normally we default to -O2. It would be nice to un-bundle MAME some more, and the only way I know how to deal with Lua, is to provide a liblua that is built with C++: https://gitlab.archlinux.org/archlinux/packaging/packages/lua/-/commit/4e97e19d9d1e95dc95c441825df1845921fdc643 Also, the Lua in question, is probably the Lua that is bundled with GENie, adding more fun to the scenario, which I believe is 5.3, I vaguely recall trying to unbundle that too. > Unless I misread the logs it looked like OPTIMIZE=0 didn't define -O at all? > If we assume I didn't misread the build log we don't override the framework without a good reason and that is usually done by a toggle. > https://cgit.freebsd.org/ports/tree/Mk/bsd.options.desc.mk#n396 > https://docs.freebsd.org/en/books/porters-handbook/book/#dads-cflags Will investigate, and add an option for optimised builds. > To be honest, I assumed that nonag removed this screen ( https://imgur.com/AMEyCLY) without looking more closely at it. I tested Pac-Man 1980 by Midway on 0.260, and this Reagan era (influenced by a lovely and compassionate Monarch, Bloody Mary) shit did not present itself. I asked my housemate, to ask his sister's best friend's, second cousin's work mate's aunty to test other ille%!*$ obtained ROMs, no message was presented. > It's been a while since I last used MAME :/ It has come a very long way, I highly recommend it on nostalgia (arcade gaming or otherwise) alone. On FreeBSD we are getting closer to matching the primary MAME platforms for providing a featureful MAME out of the box, the work of many FreeBSD users. > About the patch, http://forum.arcadecontrols.com/index.php/topic,164449.0.html From what I can gather, that patch adds some build or CI glue, as well as bringing in GrooveyMAME's support for multiple displays, which is super awesome. It includes a driver for some ATI/AMD GPU, a KMS backend, a new bundled library switchres, DirectX drivers, and more. The patch is large, 20218 lines, unless someone really screams out for some features of GrooveyMAME, I am probably not going to work on breaking that patch out into it's logical and usable components. > https://github.com/antonioginer/GroovyMAME/releases/ It maybe better to just add a new port for GrooveyMAME. There are other additions/extras for MAME, like a hardware/software database, which improves the UI/UX with added media, and information, the name or location of that project escape me at the moment, however it is another item I think I would like to include eventually. Thanks for the help.
If you add an OPENMP option, make sure it is only present if the file /usr/include/omp.h exists. Otherwise OPENMP is not supported and must not be enabled. This is the case e.g. on armv7. So for example do .if !exists(/usr/include/omp.h) OPTIONS_EXCLUDE= OPENMP .endif Will let diizzy handle the rest.
(In reply to Robert Clausecker from comment #7) Hi Robery, sure thing, thanks. > .if !exists(/usr/include/omp.h) > OPTIONS_EXCLUDE= OPENMP > .endif Wondering if > OPTIONS_EXCLUDE_armv7= OPENMP would do the same?
Yes, I would actually prefer that one
(In reply to Daniel Engberg from comment #2) > Initial compile of lua(?) right at the beginning overrides framework, ... "-Wall -Wextra -Os" So this is the premake part of the entire build. At this stage, GENie is getting built, with a bundled configuration for FreeBSD, this includes another bundled Lua, not the same bundled Lua that MAME requires. The configuration produces a binary for Release, and the build makefile makes use of ${CXXFLAGS} and ${CFLAGS}. I noticed that using ${CXXFLAGS} in the Port Makefile was dropping the options SSE2 and OPTIMIZE for MAME, so I removed using that directly, still, not all of the MAME build options of OPTIMIZE are being used. USE_SYSTEM_LIB_ASIO=1 is working. More work ongoing.
(In reply to Daniel Engberg from comment #9) Using OPTIONS_EXCLUDE_armv7 is wrong as armv6 is too affected. And it's doubly wrong as it will still exclude to OPENMP option on future releases where OpenMP might be supported. The criterion we are testing for is the presence of OpenMP, not whether the architecture is armv7. > So this is the premake part of the entire build. At this stage, GENie is > getting built, with a bundled configuration for FreeBSD, this includes another > bundled Lua, not the same bundled Lua that MAME requires. In case you can't get this patched, I think there's no problem if a build tool is built without our CFLAGS, as long as the final binary is.
We're likely not going to see much attention for armv6 as no wants more or less wants to dead with it anymore? https://wiki.freebsd.org/DeprecationPlan Regarding ports general recommendation that I've been told by multiple people in my early days as a committer to avoid in .if statments as they make things more complicated in general and my personal experience also says the same but it's not a hard requirement by any means. Alternative way of doing it https://cgit.freebsd.org/ports/tree/audio/soundtouch/Makefile
(In reply to Daniel Engberg from comment #12) Dude, stop with that already. I know you don't care about anything that is not tier 1, but as long as armv6 is an architecture we support, it needs to be considered. The patch is wrong and would need to be fixed in the future. Just do it correctly and test for OpenMP instead of manually enumerating the architectures on which there is no OpenMP. The way the soundtouch port does it is just as stupid; an ever growing list of special cases and exceptions that may need to be adjusted with each new FreeBSD release. Is your goal creating more work in perpetuy? Just do it right once and you don't have to touch it in the future. And -Ofast should never be used by default. It is a dangerous option that only causes trouble.
(In reply to Alastair Hogge from comment #10) Great work :-) Robert, please refrain personal accusations that is uncalled for not to mention irrelevant to the discussion. Mind our code of conduct and feel free to send me a mail if you want to discuss things further. Lets keep the rest of the discussion clean and improve the MAME port.
Well, at the rate I am going, the patch might not be ready before armv6 is depreciated 😂️🤣️ I am thinking of removing the OPTIMIZE option, or the OPTIMIZE choices I currenly have. With OPTIMIZE, the MAME build adds -O3, and -fno-strict-aliasing, which is already covered by ${CXXFLAGS}, however, I really wonder if adding all these C++ compiler options for performance and size are worth it...
OK, I have managed to unbundle GENie from the MAME build, and rely on devel/genie instead, however, I have had to use the GENie patches from MAME for devel/genie so MAME builds. I also updated the GENie port. But there are still problems with using devel/genie that I am still looking into, namely that the MAME build want's to regenerate everything again, but slower, and then only build with one CPU. Still could be sometime. Still unsure if this is the correct route.
OK, I should have an updated patch to upload soon. Some info I collected on the various build options: > ┏━━━━━━━━━━━━━━┯━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━┓ > ┃ OPTIMISATION │ OPTION │ OTHER NOTES │ SIZE ┃ > ┠──────────────┼────────┼─────────────────────┼────────────┃ > ┃ Debug │ none │ │ 1030739776 ┃ > ┃ None │ none │ │ 275110856 ┃ > ┃ Size │ none │ │ 245282568 ┃ > ┃ Speed │ none │ │ 282389808 ┃ > ┃ Speed │ all │ │ 282896584 ┃ > ┃ Speed │ all │ without LDFLAGS=-s │ 381968376 ┃ > ┗━━━━━━━━━━━━━━┷━━━━━━━━┷━━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━┛ Results are just from a build directly on my host, not via poudriere.
Created attachment 246323 [details] Update to 0.260; unbundle GENie; house keeping; Updated patch hopefully addressing all (I think?) criticism. poudreire-tesport: > 12.4-{amd64,i386}-release (default options) : OK > 13.2-{amd64,i386}-release (default options) : OK > 14.0-{amd64,i386}-rc4 (default options) : OK > main-{amd64,i386}-current (All options on/off; optimisation debug on/off) : OK Thanks for the help all.
Created attachment 246331 [details] Update to 0.260; unbundle GENie; house keeping * Reduce diff files/patch-makefile * Use -O3 over -Ofast for speed focused compiler flags
Comment on attachment 246331 [details] Update to 0.260; unbundle GENie; house keeping Will update with tested 0.261 patch.
Created attachment 246679 [details] Update to 0.261; unbundle GENie; Port house keeping Update to 0.261: https://www.mamedev.org/?p=532
0.261 diff: 12.4-{amd64,i386}-release poudriere-testport OK 13.2-{amd64,i386}-release poudriere-testport OK 14.0-{amd64,i386}-release poudriere-testport OK main-{amd64,i386}-release poudriere-testport OK
Created attachment 246947 [details] Update to 0.261; unbundle GENie; Port house keeping * De-depulicate "3rdparty/dxsdk" from ${_DIST_EXCLUDES} * Somme commit message editing
Anything else you want to add? I'll commit it soon otherwise and many thanks working on this!
Yes. I might be able to drop two patches, and there is some disk IO in the patch that I think can be removed. Thanks.
Created attachment 247332 [details] emulators/mame: Update to 0.261 Updated patch, will mark approval after poudriere-testport. * Drop some patches that are not required for unbundling GENie * Add comments to some patches * Move "${RM} -r ${WRKSRC}/docs/build/html/_sources" from do-build-DOCS-on, to "-not -regex ^./_sources.*" in do-install-DOCS-on
Created attachment 247333 [details] emulators/mame: Update to 0.261 Remove typo from Makefile.
Comment on attachment 247333 [details] emulators/mame: Update to 0.261 poudriere-testport: 12.4-{amd64,i386}-release: OK 13.2-{amd64,i386}-release: OK 14.0-{amd64,i386}-release: OK main-{amd64,i386} : OK
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=9347c06ee7a1a115879ffd3d212586ae7b2788da commit 9347c06ee7a1a115879ffd3d212586ae7b2788da Author: Alastair Hogge <agh@riseup.net> AuthorDate: 2023-12-31 07:28:23 +0000 Commit: Daniel Engberg <diizzy@FreeBSD.org> CommitDate: 2023-12-31 07:34:21 +0000 emulators/mame: Update to 0.261 * Make use of ${EXTRACT_AFTER_ARGS} for a number of files/dirs that are not required for MAME on FreeBSD, this removes some post-patch work from the Makefile * Avoid extracting bgfx shaders for proprietary systems * Avoid extracting the man page for ldplayer, as it is not built * Update option TOOLS description * Increase the default amount of information produced when built with DEBUG * Drop the conditional logic for powerpc, and use LLVM-16 for all FreeBSD-14+ builds * Move some NLS logic deleting .po files to ${COPYTREE_SHARE}, and simple exclude copying those files to ${STAGEDIR}. This was originally in the wrong Makefile target, port-build * Add two more MAME ${SUBTARGETS} as tools; mamevirtual provides similar ldplayer functionality thru the MAME GUI * Remove hard-coded names from do-install-TOOLS-on Makefile target * Remove local upstream patches that were required to build 0.259 * Reduce diff files/patch-makefile * Use -O3 over -Ofast for speed focused compiler flags * Drop some patches that are not required for unbundling GENie * Add comments to some patches * Move "${RM} -r ${WRKSRC}/docs/build/html/_sources" from do-build-DOCS-on, to "-not -regex ^./_sources.*" in do-install-DOCS-on Changelog: https://www.mamedev.org/?p=532 PR: 274783 emulators/mame/Makefile | 191 +++---- emulators/mame/distinfo | 6 +- .../files/patch-3rdparty_bx_include_bx_bx.h (new) | 12 + .../mame/files/patch-3rdparty_bx_makefile (new) | 13 + ...rty_genie_build_gmake.freebsd_genie.make (gone) | 63 --- .../patch-3rdparty_genie_src_host_scripts.c (gone) | 16 - .../patch-3rdparty_genie_src_tools_gcc.lua (gone) | 15 - ...rdparty_genie_tests_test__gmake__cpp.lua (gone) | 15 - emulators/mame/files/patch-makefile | 30 +- emulators/mame/files/patch-scripts_genie.lua (new) | 34 ++ .../mame/files/patch-scripts_src_main.lua (new) | 21 + .../files/patch-scripts_src_osd_modules.lua (new) | 43 ++ .../mame/files/patch-scripts_src_osd_sdl.lua (new) | 24 + .../files/patch-scripts_src_osd_sdl__cfg.lua (new) | 45 ++ .../patch-src_devices_cpu_sh_sh7021.cpp (gone) | 10 - .../patch-src_devices_cpu_sh_sh7032.cpp (gone) | 10 - ...osd_modules_render_bgfx_shadermanager.cpp (new) | 21 + emulators/mame/files/patch-src_osd_sdl_sdlprefix.h | 2 + emulators/mame/pkg-plist | 566 +-------------------- 19 files changed, 354 insertions(+), 783 deletions(-)
Committed, thanks for your patience and commitment working on this! Best regards, Daniel