Date: Tue, 31 Oct 2023 01:38:05 +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-wOgxhhJhc2@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 #6 from Alastair Hogge <agh@riseup.net> --- (In reply to Daniel Engberg from comment #5) Hello =F0=9F=91=8B=EF=B8=8F 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 t= he 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 bu= ild config, and regenerate the build state, or maybe I did, but the resulting b= uild failed. GENie is a premake successor from memory, it is not a build/make to= ol, 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 p= oint 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 depend= ency order problems, and during a parallel build, some source files are incorrec= tly built out-of-order, and the build fails. One such common problem has now be= en addressed, but it is a hack to get around GENie=E2=80=94initially 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, a= nd then poudriere-testport could only use 1 thread, the next month, or week, it was the other way around=E2=80=94I would have to use 1 thread directly on m= y 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 i= t, and trying to reduce file I/O some more in the Makefile, I am not sure if t= hat GENie work, if it comes to fruition, will make it for this update, I have o= ther priorities. > I got the impression by having a quick look that PROFILER=3D0 amd SYMBOLS= =3D0 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=3D"zenasm" supported=3D"no= "> >./3rdparty/genie/src/host/scripts.c:490: "erincludedirs), tool.gets= ystemincludedirs(cfg.systemincludedirs))),\ncppflags =3D ninja.list(tool.g= etcppflags(cfg)),\nasmflags =3D ninja.list(table.join(tool.getcflags(cfg),= cfg.buildoptions, cfg.buildoptions_asm)),\ncflags =3D ninja.list(table.= join(tool.getcflags(cfg), cfg.buildoptions, cfg.buildoptions_c)),\ncxxflags= =3D ninja.list(table.join(tool.getcflags(cfg), tool.getcxxflags(cfg), cfg= .buildoptions, cfg.buildoptions_cpp)),\nobjcflags =3D ninja.list(table.join= (tool.getcflags(cfg), tool.getcxxflags(cfg), cfg.buildoptions, cfg.buildopt= ions_objc)),\n}\n_p(\"\")\n_p(\"# core rules for \" .. cfg.name)\n_p(\"rule= cc\")\n_p(\" command =3D \" .. wrap_ninja_cmd(tool.cc .. \" $defines = $includes $flags -MMD -MF $out.d -c -o $out $in\"))\n_p(\" description =3D= cc $out\")\n_p(\" depfile =3D $out.d\")\n_p(\" deps =3D gcc\"= )\n_p(\"\")\n_p(\"rule cxx\")\n_p(\" command =3D \" .. wrap_ninja_cmd(= tool.cxx .. \" $defines $includes $flags -MMD -MF $out.d -c -o $out $in\"))= \n_p(\" description =3D cxx $out\")\n_p(\" de" > ./3rdparty/genie/src/host/scripts.c.orig:490: "erincludedirs), tool.get= systemincludedirs(cfg.systemincludedirs))),\ncppflags =3D ninja.list(tool.= getcppflags(cfg)),\nasmflags =3D ninja.list(table.join(tool.getcflags(cfg)= , cfg.buildoptions, cfg.buildoptions_asm)),\ncflags =3D ninja.list(table= .join(tool.getcflags(cfg), cfg.buildoptions, cfg.buildoptions_c)),\ncxxflag= s =3D ninja.list(table.join(tool.getcflags(cfg), tool.getcxxflags(cfg), cf= g.buildoptions, cfg.buildoptions_cpp)),\nobjcflags =3D ninja.list(table.joi= n(tool.getcflags(cfg), tool.getcxxflags(cfg), cfg.buildoptions, cfg.buildop= tions_objc)),\n}\n_p(\"\")\n_p(\"# core rules for \" .. cfg.name)\n_p(\"rul= e cc\")\n_p(\" command =3D \" .. wrap_ninja_cmd(tool.cc .. \" $defines= $includes $flags -MMD -MF $out.d -c -o $out $in\"))\n_p(\" description = =3D cc $out\")\n_p(\" depfile =3D $out.d\")\n_p(\" deps =3D gc= c\")\n_p(\"\")\n_p(\"rule cxx\")\n_p(\" command =3D \" .. wrap_ninja_c= md(tool.cxx .. \" $defines $includes $flags -MMD -MF $out.d -c -o $out $in\= "))\n_p(\" description =3D 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/4e97= e19d9d1e95dc95c441825df1845921fdc643 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=3D0 didn't define -O at= all? > If we assume I didn't misread the build log we don't override the framewo= rk 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.co= m/AMEyCLY) without looking more closely at it.=20 I tested Pac-Man 1980 by Midway on 0.260, and this Reagan era (influenced b= y 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= .=20 > It's been a while since I last used MAME :/ It has come a very long way, I highly recommend it on nostalgia (arcade gam= ing or otherwise) alone. On FreeBSD we are getting closer to matching the prima= ry 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, 2= 0218 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 databas= e, 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 ite= m I think I would like to include eventually. Thanks for the help. --=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-wOgxhhJhc2>