stefan-gr
commented
8 years ago Sooooooo... How about my last pull request, huh?
No worries, I noticed that I had to hurry the hell up only after commiting :sweat_smile: . It was only broken for new users in that timeframe anyway, no harm done.
To make it up to you... it's yet another wacky pull request. Bam!
Pls, no.
Libretro Eclasses
Oh jesus, yes that's nice. I forgive you, please continue being awesome.
Altogether, this should help reduce boilerplate code in core ebuilds and simplify future changes to such code. You know, so that leycec's problems stop becoming your problems.
It will, I can't wait to abuse the eclasses to do my bidding.
This pull request also adds a new core: endrift's mGBA, a next-generation GBA emulator that absolutely rocks the 8-bit Casbah. Decently recommended for your next GBA crack fix! :syringe:
We never can have enough GBA cores, now can we? :smiley:
This core has also been added to libretro-meta. I briefly contemplated replacing vbam with mgba as the default GBA core, but ultimately conceded that that was one step too far over the red line. Sadly, vbam remains the default.
The meta build was almost done at random, though I did try to pick the most active and easiest to compile as defaults. Nothing stops mgba from replacing vbam, especially since it is actively maintained and has sweet sweet pgo.
If you're opposed (i.e., "Thin manifest izt ev1l!"), that's totally cool. I'll just cut that commit out.
It's cool, I knew that this was an option but never bothered to look further into that, I'm a slacker.
Over the coming days, I'd like to systematically refactor the existing Libretro core ebuilds to leverage the new libretro-core.eclass. Currently, the mGBA core is the only one to do so. Again, I'm really, really sorry for dropping the open-source ball there.
No need to feel down about that. That's what open source is about, isn't it? :smiley:
Thanks for picking up the slack! You are Awesome Man incarnate. Also, here's free beer. :beers:
My pleasure. Thanks for the free, as in freedom, beer.
Now to merge this and try out that new mgba.
Sooooooo... How about my last pull request, huh?
Yeah, it sort of sucked. I left the Libretro ebuilds in a broken state by failing to globally apply the new games-specific paths applied to the Retroarch ebuild, requiring you to pick up the broken shards and stitch things back together. I'm really, really sorry about that. Wouldn't blame you for wanting to punch me in my thick mellon head. :melon:
To make it up to you... it's yet another wacky pull request. Bam!
Libretro Eclasses
There's quite a bit of duplicate code between the various Libretro core ebuilds. This pull request adds the following two new eclasses to help simplify the development of future Libretro core ebuilds and maintenance of existing Libretro core ebuilds:
libretro.eclassAt the moment, this eclass only defines four globals providing the absolute paths of common Libretro and Retroarch directories:
LIBRETRO_LIB_DIR, the absolute path of the directory containing Libretro shared libraries.RETROARCH_LIB_DIR, the absolute path of the directory containing Retroarch shared libraries.LIBRETRO_DATA_DIR, the absolute path of the directory containing Libretro data files.RETROARCH_DATA_DIR, the absolute path of the directory containing Retroarch data files.Also,
retroarch-9999.ebuildhas been refactored to leverage these globals.libretro-core.eclassHere's where the good times roll. This eclass centralizes common logic shared between Libretro core ebuilds, defining one global intended to be overridden by cores (...and several globals not intended to be overridden):
LIBRETRO_CORE_NAME, the name of the current Libretro core being installed. Defaults to the name of the current package excluding the-libretrosuffix (e.g.,mgbafor themgba-libretrocore).This eclass also exports two phase functions:
libretro-core_src_unpack(), automating the fetching and checking out of the Libretro core info database.libretro-core_src_install(), automating the installation of both:${WORKDIR}/infos/dist/info/${LIBRETRO_CORE_NAME}_libretro.info.${S}/${LIBRETRO_CORE_NAME}_libretro.so.Altogether, this should help reduce boilerplate code in core ebuilds and simplify future changes to such code. You know, so that leycec's problems stop becoming your problems.
New Core! It's mGBA.
This pull request also adds a new core: endrift's mGBA, a next-generation GBA emulator that absolutely rocks the 8-bit Casbah. Decently recommended for your next GBA crack fix! :syringe:
This core leverages the new
libretro-core.eclassdescribed above. It also supports an ungodly number of USE flags – includingltofor link-time optimization andpgofor profile-guided optimization – all of which superficially appear to work. (Did I mention that mGBA is bonkers crazy? Yeah, 'cause it is.)This core has also been added to
libretro-meta. I briefly contemplated replacingvbamwithmgbaas the default GBA core, but ultimately conceded that that was one step too far over the red line. Sadly,vbamremains the default.Give it a try, though. Let me know if it mildly impresses you.
Thin Overlay Manifests
I... I couldn't take it anymore. So I also enabled thin manifests in the repository's
metadata/layout.conffile. The idea here is thatgitalready checksums all committed files, so there's little point in Portage requiring these files to be checksummed yet again in per-ebuildManifestfiles.I've had thin manifests enabled on raiagent for... like, ever. And it's a development godsend. Not having to manually re-checksum files after changes dramatically sped up the development of this pull request.
If you're opposed (i.e., "Thin manifest izt ev1l!"), that's totally cool. I'll just cut that commit out.
What Is Next Then?
Over the coming days, I'd like to systematically refactor the existing Libretro core ebuilds to leverage the new
libretro-core.eclass. Currently, the mGBA core is the only one to do so. Again, I'm really, really sorry for dropping the open-source ball there.Thanks for picking up the slack! You are Awesome Man incarnate. Also, here's free beer. :beers: