Created attachment 408252 [details] sdlmame-0.164s.ebuild Attached is a version bump to sdlmame-0.164 with a few differences from the 0.149 version currently in portage. games-emulation/sdlmess has been incorporated upstream into the MAME project. games-emulation/sdlmametools has been incorporated into this ebuild as a 'tools' useflag. As such, games-emulation/sdlmess and games-emulation/sdlmametools are soft blocked in this new sdlmame-0.164 ebuild. The current problems with dev-lang/lua for the past few years (bug #407091) have meant that dev-lang/lua remains hard masked. Thus sdlmame is instructed to build using it's bundled version of dev-lang/lua:5.3 instead of relying on an external version until dev-lang/lua in portage can be resolved. The ebuild also has the added benefit of not needing any external files in the way of patches or configs, all that is needed is contained within the ebuild. Thanks :)
Looks like the "s" just means "source" so it shouldn't be part of the version, right?
Also, needs to respect build variables and flags.
(In reply to Mr. Bones. from comment #1) > Looks like the "s" just means "source" so it shouldn't be part of the > version, right? Yes you're right, didn't notice that. Are you able to make it so? (In reply to Mr. Bones. from comment #2) > Also, needs to respect build variables and flags. Which ones do you mean? The source does already transparently respect CFLAGS/CXXFLAGS...
it doesn't respect CC, CXX, AR, PYTHON. Also fails for me with USE="debug -opengl"
(In reply to Mr. Bones. from comment #4) > it doesn't respect CC, CXX, AR, PYTHON. Also fails for me with > USE="debug -opengl" I wasn't able to reproduce the disrespecting of those variables. Maybe my test method was flawed but all those variables were respected. Interesting the global makefile suggests python3 is the preferred ABI in: makefile:# PYTHON_EXECUTABLE = python3 However, there are still some python2 only scripts that will cause build failure if python3 ABI is selected. All good, the ebuild doesn't use python3 anyway. I was able to reproduce the '-opengl' failure right at the end at linktime because it tries to USE_BGFX which fails to link when it can't see GL libs functionality. Will probably need to do 'disable_feature USE_BGFX' if 'USE=-opengl' is set. Another improvement would be to enable/disable all features using 'usex' function from eutils.eclass (examples already present) instead of uncommenting lines in makefile with the local 'enable_feature' and 'disable_feature' functions.
Confirmed. Adding 'USE_BGFX=$(usex opengl "1" "0")' to emake args fixes the 'USE=-opengl' linking build failure.
Created attachment 408830 [details] Revised sdlmame-0.164.ebuild Remove 's' from version string Adds USE_BGFX state depending on USE=opengl Tidy up ebuild by using emake arguments instead of sed'ing makefile
I think we want to just turn off bgfx. Generally we don't want to use embedded libraries. In the case of lua, the currently situation with 5.2 in the tree doesn't look like it's going to resolve soon so it's worth using the embedded version to keep up with the versions but bgfx isn't in the tree so I'd rather just turn it off. Also, building the embedded lua didn't look like it was honoring AR.
Created attachment 409706 [details] sdlmame-0.164-r2.ebuild OK revised ebuild attached: BGFX is turned off. Added 'softlists' USE flag as we were missing optionally installing the MESS software lists into the hash/ directory. What do you think, ready to be included into the portage tree?
*** Bug 496654 has been marked as a duplicate of this bug. ***
sdlmame-0.167 is in portage. thanks for the bug report and ebuild work.
