[Bug 274783] emulators/mame: Update to 0.260

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274783

--- Comment #6 from Alastair Hogge <agh@riseup.net> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.