Re: [hatari-devel] Any interest in accepting RetroArch libretro core patches?

[ Thread Index | Date Index | More Archives ]

On 22 August 2016 at 05:15, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:
> Hi,
> On 08/20/2016 09:29 PM, David Savinkoff wrote:
>> ----- Jamie Bainbridge wrote:
>>> You may be aware of an emulator project called RetroArch at
>>> RetroArch is an framework which takes existing emulators, librarises
>>> them into "cores", and executes the core through an existing generic
>>> display/sound/input frontend. The result for end users is that they
>>> configure the frontend once and all their emulators just work. It's
>>> really great!
>>> Hatari has been a libretro core since 1.8.0 with a shallow fork at
>>> created by one of the main
>>> RetroArch developers
>>> You can see the 20-or-so patches required to add RetroArch support.
>>> They are mostly self-contained in the libretro/ directory, though
>>> there are a few display/sound/input changes through the code which are
>>> separated with "#ifdef __LIBRETRO__". These patches appear to apply
>>> cleanly over the Hatari 1.9.0 source.
>>> I am writing to ask if you would like to add these libretro patches
>>> directly into Hatari?
>> (my opinion)
>> If you could provide a source code
>> diff -ur hatari-1.9.0 hatari-1.9.0-libretro > hatari-1.9.0-libretro.diff
>> that applies as a patch with
>> patch -p0 < hatari-1.9.0-libretro.diff
>> to hatari-1.9.0.tar.gz
>> that compiles from source into a working executable.
>> This would provide the most concise information for all.
> Better to mail the patches as separate attachments to the list,
> to discuss which of the patches would be OK to be folded into
> Hatari sources.

Thank you for the replies. I will try get the patches compiling
against 1.9.0 and report back with patch attachments if I'm


>>> This would allow your source tree to just automatically be built as a
>>> RetroArch core. The default is to build as Hatari currently does,
>>> __LIBRETRO__ must be explicitly defined during build for the
>>> preprocessor to create the RetroArch core, so hopefully you consider
>>> this a non-invasive change to accept.
>>> I ask this because I would like to update RetroArch's Hatari to v1.9.0
>>> and to future versions as well, but this requires converting hg to
>>> git, then either rewriting upstream git history with a rebase of
>>> 1.8-to-1.9 and rebase of libretro changes and force push, or a lot of
>>> manual tedious merge conflict work to apply 1.9 directly over the
>>> current tree.
>>> It would make a RetroArch Hatari core a lot easier if your upstream
>>> repo supported it already.
>>> Jamie

Mail converted by MHonArc 2.6.19+