[Bug 274783] emulators/mame: Update to 0.260

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

--- 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=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.

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