From nobody Tue Oct 31 01:38:05 2023 X-Original-To: ports-bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SKCSs3CLGz4ygTk for ; Tue, 31 Oct 2023 01:38:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SKCSs0SX6z3FR6 for ; Tue, 31 Oct 2023 01:38:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1698716285; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pg7QwQbl8gG6dtlpjqUVT5o9EQIAKoxOAm6XIPQHVYw=; b=NIZWqOSqJP/jp6fLcsFubzIAq9QVt8uioOfxFK6necH6qzv34W7EN7MQYabrUyvCT5O0zN sIBwpkL45TqmT2/gBm4qF0AK0NFQmLp/vVdXgWrx8mnMzpiHJZDAlOsZryvC24Zk61ZiDV N19Ok8OU9h7Fu++S2/6KfUTWvyVef4t3BW9dAbw1kTd5VEwlKbANgQ8XcfAL8y3h2IvWLC JuF4LxBfB1KAqRd0lryQ1kT1hiByV730rRzu/zDACQIH2LCTf3jZbtTaX0M5ResjDdvBUe 6ZDKfVSYPSyUGkck0mEYUkbJJyhuw6hqiDusPLPeWtMRsoqwv7kKqKQSnXdtZg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1698716285; a=rsa-sha256; cv=none; b=XFLS/MNnUK49z9vpvxOTMWkdH/T06qOZGNs9+mcpPMpZReLrLXq7AsitD5KVFMbiq5KYxM hsiCaypUO5NH8AoKBIVg1k3IohQEpfJTMVHq6dfrPBH9RaAcPWHmn/FEbqdscn7vu9upBZ 3faDghO4V267jslkK51SHvkPT4WPD7yniQ9p5xQQh8LV74VyjDObEjzW6lPaHJxH5Eb0fw QpAXGpg/61M9BFAOatBeRfcN+8JCpbfWlH7EfgnrlnJI202Q0wmHUfagvSSpB9h2XgrhVS Ll2OyG4OULYdBhWHq0ODRZ4TI6tCOElEWh5/v1+Elo0eflzXK4DemQEmxJCrvA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4SKCSr6fp2zkvn for ; Tue, 31 Oct 2023 01:38:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 39V1c4nl018469 for ; Tue, 31 Oct 2023 01:38:04 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 39V1c4Ac018468 for ports-bugs@FreeBSD.org; Tue, 31 Oct 2023 01:38:04 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 274783] emulators/mame: Update to 0.260 Date: Tue, 31 Oct 2023 01:38:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: agh@riseup.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ports-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Ports bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-ports-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports-bugs@freebsd.org X-BeenThere: freebsd-ports-bugs@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D274783 --- Comment #6 from Alastair Hogge --- (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: >./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.=