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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

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
> > http://www.libretro.com/
> >
> > 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
> > https://github.com/libretro/hatari 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.


	- Eero

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