Update recipes

docs/README.MacOSX.md

@@ -1,110 +0,0 @@
-# Requirements for libretro-super on OS X
-
-As of this writing, OS X support for libretro-super requires use of a Terminal
-application.  You'll also need Apple's Xcode, a set of command line tools for
-your versionf of Xcode, and possibly also the source code management tool git.
-
-## OS X 10.7 Lion and later
-
-As of OS X 10.7, the correct way to get Xcode is via the Mac App Store.  If
-you've been keeping up with OS X versions, you may simply go to the App Store
-page for [Xcode](https://itunes.apple.com/us/app/xcode/id497799835?mt=12) and
-click the friendly GET or iCloud download button, as appropriate.  An annoying
-bug recently observed (as of 2015 February) is that you cannot download old
-versions of App Store programs unless you have already "purchased" the app.
-
-In that case, go to [Apple Developer Connection](http://developer.apple.com/)
-and find it there.  It's buried and Apple tends to move it around
-periodically, sorry.
-
-Once you have installed Xcode (version 4+), open it and go into Preferences.
-Select the Downloads pane, and click the Install button for Command Line
-Tools.  Every time you upgrade Xcode, you'll want to back here to see if
-Command Line Tools needs upgrading.
-
-Once you've done that, check the section below about ``git``.
-
-
-## OS X 10.5 Leopard and 10.6 Snow Leopard (and older?)
-
-While the final versionf of OS X 10.6 did feature the Mac App Store, Xcode for
-these versions generally came with the system installation media or a retail
-OS X install disc.  Even so, a more recent version is probably available for
-you at [Apple Developer Connection](http://developer.apple.com/) and it's
-generally wise to have the latest version intended for your OS version.  OS X
-Leopard can use up to Xcode 3.1 versions, which are the last ones to run
-natively on PowerPC and the first to support compiling for iPhoneOS (yes,
-pre-iPad!)
-
-Xcode 3.2 is still able to compile PowerPC binaries, however like the OS X
-Snow Leopard it runs on, you'll need an Intel processor to use it.
-
-Older versions of OS X are not officially supported at this time, but if you
-are more technically inclined, you might be able to make it work.  If you get
-it to work, please send us a patch!  Obviously any version of Xcode predating
-10.4.6 will not support Intel processors.
-
-You will need to install git if you haven't already done so.
-
-## git
-
-On recent versions of OS X, you may already have git installed by Apple.  To
-check, open up a terminal and type the command (without quotes) "``which
-git``".  If you get another shell prompt without any output, you definitely
-need to install git.  If you see a UNIX path name to git, then you're probably
-good to go.  ``/usr/bin/git`` is the version supplied by Apple.  If it lives
-somewhere else it was either compiled by hand or installed by source ports
-system.  If you don't have it, a source ports system is a good way to get it.
-Here's a few choices:
-
- * [MacPorts](http://www.macports.org/)
- * [HomeBrew](http://brew.sh/)
- * [Fink](http://www.finkproject.org/)
-
-Of these, Fink tends to be the heaviest and HomeBrew the lightest.
-
-One common criticism of HomeBrew is that using it tends to suggest downloading
-ruby scripts right off the Internet and running them sight-unseen, with admin
-access to your system.  If that sounds unwise, HomeBrew isn't for you.  That
-said, think about the last commercial program you installed on your Mac.  Did
-you look at its source code before verifying it was safe to run after you
-downloaded it off the Internet?
-
-MacPorts is somewhere in the middle, depending on how good you are at cleaning
-up old "inactive" versions of things (use ``port -cu upgrade outdated`` when
-you upgrade to keep things tidy.)  Your author uses MacPorts for all but a
-couple of rare items not packaged by that port system.  That and check a
-port's variants before installing it to make sure it has the features you
-want, and disables the ones you don't.
-
-Fink tends to follow the Debian model, which means lots of libraries needed
-for optional features, just in case.  That's disk space used on a release
-version, and lots of time compiling all of those libs if you are running a
-pre-release.
-
-Or you could just go and find git's website, download it, and follow the
-instructions.  A basic Mac with Xcode installed probably meets all necessary
-requirements.
-
-<!-- FIXME: Too much handholding here? -->
-
-
-# Using libretro-super
-
-TODO: Works the same as libretro-super for Linux or under MSYS2 from here.
-Document what that means exactly, later.
-
-Nutshell version:
-
- * ``git clone https://github.com/libretro/libretro-super.git && cd libretro-super``
-   or
-   ``cd ~/path/to/libretro-super``
- * ``./libretro-upgrade.sh``
- * ``./libretro-fetch.sh``
- * ``./libretro-build.sh``
-
-You get the idea.  You shouldn't need to run libretro-upgrade.sh after a fresh
-clone—it's there to handle cross-module moves, renames, and deletions that git
-cannot handle.
-
-<!-- vim: set tw=78 ft=markdown: -->

docs/devel/README.iKarith.md

@@ -1,456 +0,0 @@
-First, an introduction is in order:
-
-Hi, I'm iKarith, and probably you don't know me.  :)  I'm not really part of
-any "scene" or anything.  Long story short, I wanted to build a stand-alone
-emulator-based box for my fiancée and thought RetroArch might give her
-something clean, seamless, and foolproof once I set it up.  And as some of
-you who haven't been big fans of RetroArch may guess, that wasn't easy.
-
-Two choices existed: Complain, or fix it.  I chose to fix it.  And when I
-found out where things were headed for RetroArch, I decided to first see about
-improving its build process.
-
-To that end, this file and the files in the repo with "iKarith" in the name
-were created.  They're temporary and will go away once this project's done.
-This file in particular explains what I'm doing and why.  So read on if that
-stuff interests you.  :)
-
-iKarith, 2015-02-07
-
-## History
-
-2015-02-17.0: Updated to reflect the now deleted iKarith files
-              There are changes to the planned implementation not discussed
-	      here yet, so just know that that section is still obsolete.  It
-	      is still in the RFC stage, though, so it can wait a day or two.
-2015-02-08.1: Extensive rewrite of future direction portions
-2015-02-08.0: Added discussion of dependencies
-2015-02-07.1: Changed heading levels
-2015-02-07.0: initial writing
-
-## Some philosophy
-
-Libretro should be an API, not a project.  You might want to argue with me as
-to whether or not that's true.  And you might be surprised to find me agree
-that as of today, it *is* a project and not an API.  But that model is IMO not
-infinitely sustainable.  You can't just fork every open source game project
-out there.
-
-You can't even do that with all the emulators.  And even if you could, it'd be
-a nightmare trying to compile them all, let alone maintain them.  And it's
-just not realistic to hand a user a dozen SNES emulators with no explanation
-of what's what and expect them to know what to do with them all, especially
-since there are multiple versions of some of them.  Now multiply that by all
-of the systems and all of the emulator engines and all of the versions of some
-of them that exist.  It just does not scale.
-
-
-### The technical problem
-
-Leaving aside the philosophical direction of where libretro is headed for a
-moment, its build scripts don't really function well for where the project is
-at today, let alone in the future when it's "not really a project" anymore.
-
-You see, libretro does not have one build script.  In fact, it doesn't even
-have one build script per target platform.  No, there's the combination of
-libretro-fetch.sh, libretro-build.sh, and retroarch-build.sh and their
-included subscript dependencies.  In addition, there's about a dozen or so
-platform-specific build scripts which have some overlap with the main scripts
-and (inconsistently) use their dependent subscripts.  In addition, there's a
-handful of XCode projects for Mac OS X which are intended to be backward
-compatible with old versions of the OS but aren't.  And there's a whole
-additional set of build scripts replacing most of these almost in their
-entirety written for the buildbot.  And then there's the Makefiles which
-are often just as much of a mess (but a separate problem…)
-
-Originally I began working on this using iKarith-\*.sh scripts which were
-copies of the build scripts in libretro-super, but were a safe sandbox for
-changing stuff.  The reason was that if you touch the mainline scripts in any
-significant way, you *will* break something.  Indeed, many of the more minor
-platform build scripts will not function at present without a (fairly trivial)
-patch to enable them to be used outside of the libretro-super directory.
-
-I'm personally leaving them in their known slightly-broken state.  Justified
-by the fact that any script that goes unpatched hasn't been tested in awhile
-and needs more careful scrutiny when its features are incorporated into the
-new build system.
-
-
-### The Political Problem?
-
-As I said, I don't really know anybody.  So I can't pretend to understand all
-of the issues involved with devs in the various "scenes" in question.  I know
-some people feel that they should retain control of their projects.  I have
-seen someone accuse libretro of trying to "steal" other projects to improve
-their own.  There are probably other issues, some of them personal, and I just
-don't know them.  And I don't need to, honestly.
-
-What I can say is that what I have in mind for the new build system makes
-libretro-super function kind of like Debian/Ubuntu's package system.  You give
-it the equivalent of an apt sources.list entry and it should be able to
-download your project from your site, build it for your system, package it,
-and possibly even give you the means to upload it to a repository.
-
-My own future interests involve building a standalone libretro player for a
-single project so that you can build something that targets the API and
-distribute it as a stand-alone game, and a small version of SDL that's built
-for libretro so that SDL-based games could be compiled for use on lakka.TV
-down the line.  Remember what I said I originally wanted to accomplish?
-
-I don't know if any of this stuff will help or hinder resolution of any
-outstanding issues between anyone.  I'm just here to make cool stuff easy
-enough for my fiancée to use it, remember?  :)
-
-
-## Dependencies
-
-For all the discussion of "no external dependencies", libretro and the stuff
-ported to it have a lot of them.  That's unavoidable, actually.  To simplify
-the argument, let's presume a GNU/Linux build environment.  You can't compile
-anything without a compiler and binutils.  And the only way you're going to
-compile large batches of code is a dependency on make.  Those are obvious.
-
-
-### The less obvious dependencies
-
-Continuing with our Linux example, all make does is give you a way to specify
-what commands are required to create/update a file, and what files it is
-created from.  From there, the commands are executed in a shell, which
-introduces a dependency on the shell, but also the shell commands.  Things
-like echo and cp are not traditionally "builtins", but rather external
-programs that were traditionally smaller than the ELF header required to tell
-Linux how to run them.  (And old enough versions of Linux didn't use ELF…)
-
-By this point you've got literally 500MB of dependencies on a modern Linux
-system.  You could argue that some of that is irrelevant because classically
-all of the above fit into 50MB on a Linux system dating back to a 1.x kernel
-and the fact that the dependencies have bloated so much (largely for UTF-8,
-translation, internationalization, etc.) isn't our problem.  That's fair
-enough, but we still have a minimum of 50MB of build dependencies on Linux.
-
-Add the build scripts in there and you add dependencies on git (which means
-also perl and possibly python though nothing we do requires anything that uses
-python until you try to build mame at least) and explicitly on bash.  I'm
-pretty sure our current build scripts will run on bash 2.05 at least, but most
-folks assume bash 4 is available on all systems these days.  (It's not—the Mac
-still comes with bash 3.)
-
-If we remove the bash dependency, we could claim a POSIX environment as a
-build dependency, but notably some platforms are not and do not even pretend
-to be POSIX, such as that little insignificant OS called Windows.  You could
-install MSYS (or more likely MSYS2) to try and fake it at the shell script
-level, but MSYS2 is one *significant* dependency.
-
-This is why autoconf exists.  It's also why autoconf is the gigantic mess
-(both in terms of size and ugly complexity) that it is: It cannot assume a
-fully POSIX system, and the POSIX standard is pretty dated anyway.  It has to
-figure out all of the quirks of UNIX-style (and non-UNIX) systems running on 8
-bit processors that haven't been updated in 35 years or more.
-
-
-### So, what's your point?
-
-The point is that we cannot say that we have no, or even few build
-dependencies.  And at present, the ones we do have are not declared.  Fixing
-this can be done in three ways, two of which aren't really worthwhile:
-
-1. We can use autoconf.  In addition to all the reasons why this idea just
-   sucks, the fact is that it won't solve our problem anyway because some
-   cores have build dependencies, even if they should be free of external
-   runtime dependencies.  Not only that, we cannot easily predict if down the
-   line you want to use libretro-super to build a core out of a mercurial or
-   subversion repository.
-
-2. We could try to reinvent autoconf for our purposes.  This has the advantage
-   that we could build a system that accommodates our build system's needs and
-   also provides a means for cores to declare additional build dependencies if
-   they need them.  It has the obvious disadvantage that no attempt to replace
-   autoconf has ever really been successful for a reason.  Either you have to
-   introduce an external dependency (as cmake did) or you have to mix a bunch
-   of 1970s-era script syntaxes like autoconf does because they're the only
-   ones you can guarantee are installed everywhere.
-
-3. We can simply state our dependencies from the outset and expect the user of
-   libretro-super to meet them.  We may have to jump through a few hoops to
-   deal with where things are installed.  For example, our scripts might be
-   best run using the same /usr/bin/env tactic used by Python developers to
-   avoid hard-coding a path that isn't portable.  I'm told that the byuu, the
-   primary developer behind bsnes/higan, has a philosophy of not limiting
-   himself to legacy cruft when something better exists.  To the extent that
-   is actually a reasonable thing to do, it's not a bad idea.
-
-   This doesn't solve the core build dependency issue by itself, but it does
-   assure that if the libretro-super user has installed the prerequisites for
-   using libretro-super, we CAN solve that problem without resorting to the
-   kind of abomination that is autoconf.
-
-Obviously I see but one choice here.  However care needs to be exercised still
-to ensure that our libretro-super dependencies are in fact __reasonable__.  I
-would love to be able to take advantage of modern versions of bash, for
-example, but Mac OS X users don't have it unless they installed it themselves.
-It's not even guaranteed with MacPorts or Fink installed, so it's a different
-issue than on Windows where people are going to have to install something no
-matter what we use.
-
-(Yes, I know bash 3 is ancient, but MacPorts and Fink both get along with it
-just fine, and only bash scripters really ever notice the difference.  If you
-want to convince Twinaphex that it's a reasonable dependency, I'll join you in
-doing so—but if it isn't packaged for PowerPC 10.5 systems, he's going to veto
-the idea from the start and so will I.  Yes, RetroArch doesn't currently build
-on 10.5 systems.  If I can reasonably correct that at some point, I will.  No,
-10.4 and older isn't necessary.)
-
-
-## The solution so far
-
-To begin, let's discuss the proof of concept I wrote before even beginning
-this README.  We can decide where it goes from there afterward.  We'll be
-using the incredibly simple 2048 project as a working example,  I like it
-because it's as close to a fully functional "hello world" for libretro as I
-can imagine.  Presently it fetches and compiles with these rules:
-
-```bash
-fetch_libretro_2048() {
-   fetch_git "$REPO_BASE/libretro/libretro-2048.git" "libretro-2048" "libretro/2048"
-}
-
-build_libretro_2048() {
-   build_libretro_generic_makefile "2048" "." "Makefile.libretro" ${FORMAT_COMPILER_TARGET}
-}
-```
-
-Okay, so I turned that into a pile of shell variables:
-
-```bash
-core_2048_dir="libretro-2048"
-core_2048_fetch=fetch_git
-core_2048_source="$REPO_BASE/libretro/libretro-2048.git"
-core_2048_build_rule=build_libretro_generic_makefile_s
-core_2048_makefile="Makefile.libretro"
-core_2048_other_args="$FORMAT_COMPILER_TARGET"
-```
-
-There's no need for $REPO_BASE for "write access" using github, and github
-actually recommends everyone use https anyway.  (They've flip-flopped on this
-a few times over the years.)
-
-The first real change here is build_libretro_generic_makefile_s, a version of
-the build_libretro_generic_makefile rule written to use a set of shell
-variables instead of positional parameters. You'll notice there's no variable
-for subdir defined because no subdir is needed and therefore the rule doesn't
-use one.
-
-The fetch and build rules could be implicit as well since those would be the
-defaults.  Actually, the only things 2048 uses that cannot be implicit
-defaults are obviously the source repository and its use of something other
-than ``makefile`` or ``Makefile``.
-
-This proof of concept uses shell variables, but it could just as easily have
-used an ini file format like so:
-
-```ini
-[2048]
-source = "https://github.com/libretro/libretro-2048.git"
-makefile = "Makefile.libretro"
-```
-
-or an RFC-822 style format ala Debian Packages files:
-
-```
-Core: 2048
-Source: https://github.com/libretro/libretro-2048.git
-Makefile: Makefile.libretro
-```
-
-or even possibly in the .info file:
-
-```ini
-display_name = "2048"
-authors = "Gabriele Cirulli"
-supported_extensions = ""
-corename = "2048"
-categories = "Game"
-systemname = "2048 game clone"
-license = "GPLv3"
-permissions = ""
-display_version = "1.0"
-supports_no_game = "true"
-source = "https://github.com/libretro/libretro-2048.git"
-makefile = "Makefile.libretro"
-```
-
-I like the notion of the second option actually even better than the third.
-I'll explain why when I get to XXX
-
-
-## Where to go from here
-
-We need a better replacement for $platform and $FORMAT_COMPILER_TARGET and its
-often identical $FORMAT_COMPILER_TARGET_ALT.  I dunno about you, but my
-primary workstation has three compiler suites installed that can collectively
-generate code for two platforms and eight major processor architectures.  I
-can currently run two of the processor architectures, compiled for either of
-the two platforms.  I used to have a computer that could run three other
-architectures on one of those platforms, but no longer do.  I have a Mac, and
-as far as libretro is concerned a present, that's all grossly oversimplified
-to just "osx".  WTF!  That's gotta be fixed.
-
-Next, as already noted there's some confusion outside of libretro circles
-about the scope of libretro, namely that it is intended to be first and
-foremost an API to be implemented by programs called "players" and packages
-called "cores".  If libretro-super is supposed to be an easy way to build
-these things, then players and cores need to simply be definitions that you
-can drop in to libretro-super and use, regardless of where they come from.
-
-
-### A better platform designation
-
-Currently the CPU you're building for is stored in the variable ARCH.  The
-platform may be specified in a couple of different formats in the $platform
-variable, and $FORMAT_COMPILER_TARGET and $FORMAT_COMPILER_TARGET_ALT in a
-canonical format.  But as I said on my Mac will all its build possibilities
-they all boil down to "osx".  At the very least, a platform designation should
-be specified as a canonical pairing of an OS target and an architecture
-target.  An evolution from what we have now would be to call my system
-``MacOSX-x86_64``.  Other valid architectures for Mac OS X are i386, ppc,
-ppc64, and ppc970.  (For those who don't know, ppc970 is compatible with ppc64
-code, but not the other way around, though I don't know how important 64 bit
-CPU support is on those G5 Macs with their typical RAM constraints.)
-
-The best way would be to determine which compilers were available for a given
-language and how to invoke them.  At least on my system Clang and one of the
-gcc's should be picked up for C, C++, and Obj-C for pretty much every
-standard.  And these would be defined for my current platform target of
-MacOSX-x86_64.
-
-But it shouldn't stop there.  On all modern x86_64 systems, it is possible to
-compile an (usually) run iX86 code.  Our build system should determine if you
-have the ability to do it and give you the option of doing so instead of or
-addition to the x86_64 option.  Users don't need that, but developers do.
-
-Likewise for PowerPC and ARM architectures, there might be more than one CPU
-target possible.
-
-Mac OS X and iOS introduce another spanner in the works in that they support
-compiling these multiple targets and joining them together using a tool called
-lipo.  The compiler will do this for you in most cases.  Basically if any
-CPU-specific features are determined by reading system headers or
-compiler-defined variables, you just specify -arch i386 -arch x86_64 on the
-compiler and linker command lines and you get both in one library/program.  If
-you're hard-coding things like whether to use 32 or 64 bit structures on the
-command line \*cough\*mupen64plus\*cough\*, you're going to have to build it
-twice and use lipo or better yet, patch the code to figure out these
-structural differences from the compile environment provided.
-
-We have some support for fat binaries on OS X currently, but it's a proof of
-concept only that illustrates the limitations of our current build scripts
-more than anything.
-
-
-### Packages files
-
-If libretro-super is going to be just a build environment for things built
-around the libretro API in a highly scalable fashion, we need a way for people
-to drop in their own fetch and build methods, as well as package rules for
-players and cores.
-
-Let's say the SuperTux developers port their game to libretro.  Pretty sweet
-right?  In order to build this using libretro-super, you'd need a set of build
-rules for it.  The SuperTux folks could provide you with a URL for a packages
-file which you could either download and drop into libretro-super yourself, or
-you could give the URL to libretro-super and let it download it for you.
-(Dependency on either wget or curl there—everybody has at least one or the
-other though so that's fine.)
-
-If you do let libretro-super download it for you, it could periodically check
-to see if it has changed and update it if needed.  Think apt-add-repository
-from Ubuntu.  Key signing and verification is not yet planned, but if you can
-come up with an intelligent and minimalistic way to do it, I'm interested. :)
-
-
-### Actions and targets
-
-At this point, libretro is a __MASSIVE__ project, which is kind of impressive
-for something that's not really supposed to be a project at all.  There are
-something approaching 70 individual cores including three versions of MAME,
-three versions of standalone bSNES, and more.  Users do not need all of that.
-The average developer doesn't even need all of that.  The only people who do
-are the people running the buildbots that package all of the stuff that is
-currently maintained by libretro developers.
-
-The whole reason libretro-super exists is to give libretro developers an easy
-way to build all of that stuff at once as it changes.  And the only people who
-need to rebuild all of it from scratch are people like me who are working on
-build system scripts.
-
-If libretro-super is going to be the standard reference build environment used
-for libretro cores and (perhaps also) players, not only does it need modular
-build targets and rules, it needs to be configurable as to what it will do,
-and what it will do it to.
-
-The average end user only needs to fetch and build the cores they want.  They
-might also want those cores installed into their player.  That needs to be
-possible.
-
-Buildbots need to fetch anything that has changed and then clean, build,
-package, and release it.  For every supported platform.  That needs to be
-possible.  :)
-
-Developers working on any package (core or player) built using libretro-super
-need to be able to run individual commands to perform individual tasks on a
-particular package or group of packages.  That too needs to be possible.
-
-Finally it is possible somewhere along the line that libretro-super might
-itself be packaged and the only people running it out of a git repository will
-be those choosing to do so.  Everyone else will have it installed somewhere on
-their system.  The commands need to work outside of the libretro-super
-directory, and the build system needs to be able to find anything currently
-just tossed into the libretro-super directory if it has been installed onto
-your system.  I won't say that this needs to be possible because to some
-limited extent, it already is.  :)
-
-
-### External sources
-
-This stuff is still a work in progress in my head (even more than compiler
-profiles by target), but here we go.
-
-Let's say the [SuperTux](http://supertux.lethargik.org/) project wants to
-target libretro.  Awesome, right?  All they would have to do is publish a link
-somewhere.  I'll make one up for the purpose of running:
-
-```bash
-./libretro-super.sh add-repo http://supertux.lethargik.org/libretro
-```
-
-Update the repo list to make sure I have the build rules and I should be able
-to just do something like this:
-
-```bash
-./libretro-super.sh auto-package supertux/SuperTux
-```
-
-This would perform all steps to build a packaged version of SuperTux for my
-system, which in this case requires a full fetch, build, and package.
-
-The package likely named ``supertux_libretro_MacOSX-x86_64.zip`` would
-contain:
-
-```
-supertux_libretro.dylib
-supertux_libretro.info
-COPYING_v3.txt
-README-libretro.txt
-```
-
-The file README-libretro.txt would be a simple blurb that this version of the
-game is built as a plugin for a libretro player and directs you to the
-SuperTux website and to information about what a libretro player is and where
-you'd find one.
-
-You'll note I adopt the Windows and frankly everything but CLI UNIX convention
-of adding an extension to COPYING.  I also chose to give it a version
-designation.
-
-
-<!-- vim: set tw=78 ts=8 sw=8 noet ft=markdown spell: -->

recipes/android/cores-android-jni

@@ -7,7 +7,7 @@ bsnes_mercury libretro-bsnes_mercury https://github.com/libretro/bsnes-mercury.g
 caprice libretro-caprice https://github.com/libretro/libretro-cap32.git YES GENERIC_JNI Makefile.libretro jni
 craft libretro-craft https://github.com/libretro/Craft.git master YES GENERIC_JNI Makefile.libretro jni
 crocods libretro-crocods https://github.com/libretro/libretro-crocods.git master YES GENERIC_JNI Makefile jni
-desmume libretro-desmume https://github.com/libretro/desmume.git master YES GENERIC_JNI Makefile.libretro desmume/src/libretro/jni
+desmume2015 libretro-desmume2015 https://github.com/libretro/desmume2015.git master YES GENERIC_JNI Makefile.libretro desmume/src/libretro/jni
 dinothawr libretro-dinothawr https://github.com/libretro/Dinothawr.git master YES GENERIC_JNI Makefile jni
 dolphin libretro-dolphin https://github.com/libretro/dolphin.git master YES GENERIC_JNI Makefile.libretro Source/Core/DolphinLibretro/jni
 dosbox libretro-dosbox https://github.com/libretro/dosbox-libretro.git master YES GENERIC_JNI Makefile.libretro jni

recipes/android/cores-android-jni-aarch64

@@ -12,7 +12,7 @@ snes9x libretro64-snes9x https://github.com/libretro/snes9x.git master YES GENER
 snes9x2010 libretro64-snes9x2010 https://github.com/libretro/snes9x2010.git master YES GENERIC_JNI Makefile jni
 craft libretro64-craft https://github.com/libretro/Craft.git master YES GENERIC_JNI Makefile.libretro jni
 crocods libretro64-crocods https://github.com/libretro/libretro-crocods.git master YES GENERIC_JNI Makefile jni
-desmume libretro64-desmume https://github.com/libretro/desmume.git master YES GENERIC_JNI Makefile.libretro desmume/src/libretro/jni
+desmume2015 libretro64-desmume2015 https://github.com/libretro/desmume2015.git master YES GENERIC_JNI Makefile.libretro desmume/src/libretro/jni
 dolphin libretro64-dolphin https://github.com/libretro/dolphin.git master YES GENERIC_JNI Makefile.libretro Source/Core/DolphinLibretro/jni
 dinothawr libretro64-dinothawr https://github.com/libretro/Dinothawr.git master YES GENERIC_JNI Makefile jni
 dosbox libretro64-dosbox https://github.com/libretro/dosbox-libretro.git master YES GENERIC_JNI Makefile.libretro jni

recipes/apple/cores-ios-generic

@@ -8,7 +8,7 @@ bsnes_mercury libretro-bsnes_mercury https://github.com/libretro/bsnes-mercury.g
 chailove libretro-chailove https://github.com/libretro/libretro-chailove.git master NO GENERIC Makefile .
 craft libretro-craft https://github.com/libretro/craft master YES GENERIC Makefile.libretro .
 crocods libretro-crocods https://github.com/libretro/libretro-crocods.git master YES GENERIC Makefile .
-desmume libretro-desmume https://github.com/libretro/desmume.git master YES GENERIC Makefile.libretro desmume
+desmume2015 libretro-desmume2015 https://github.com/libretro/desmume2015.git master YES GENERIC Makefile.libretro desmume
 dinothawr libretro-dinothawr https://github.com/libretro/Dinothawr.git master YES GENERIC Makefile .
 dosbox libretro-dosbox https://github.com/libretro/dosbox-libretro.git master YES GENERIC Makefile.libretro .
 easyrpg libretro-easyrpg https://github.com/libretro/easyrpg-libretro.git master YES GENERIC Makefile.libretro builds/libretro

recipes/apple/cores-ios9-generic

@@ -8,7 +8,7 @@ bsnes_mercury libretro-bsnes_mercury https://github.com/libretro/bsnes-mercury.g
 chailove libretro-chailove https://github.com/libretro/libretro-chailove.git master NO GENERIC Makefile .
 craft libretro-craft https://github.com/libretro/craft master YES GENERIC Makefile.libretro .
 crocods libretro-crocods https://github.com/libretro/libretro-crocods.git master YES GENERIC Makefile .
-desmume libretro-desmume https://github.com/libretro/desmume.git master YES GENERIC Makefile.libretro desmume
+desmume2015 libretro-desmume2015 https://github.com/libretro/desmume2015.git master YES GENERIC Makefile.libretro desmume
 dinothawr libretro-dinothawr https://github.com/libretro/Dinothawr.git master YES GENERIC Makefile .
 dosbox libretro-dosbox https://github.com/libretro/dosbox-libretro.git master YES GENERIC Makefile.libretro .
 easyrpg libretro-easyrpg https://github.com/libretro/easyrpg-libretro.git master YES GENERIC Makefile.libretro builds/libretro

recipes/apple/cores-osx-x64-generic

@@ -9,7 +9,7 @@ chailove libretro-chailove https://github.com/libretro/libretro-chailove.git mas
 citra libretro-citra https://github.com/libretro/citra.git master YES CMAKE Makefile build -DENABLE_LIBRETRO=1 -DENABLE_SDL2=0 -DENABLE_QT=0 -DDISABLE_LIBPNG=1 -DENABLE_WEB_SERVICE=0 -DCMAKE_BUILD_TYPE="Release" --target citra_libretro
 craft libretro-craft https://github.com/libretro/craft master YES GENERIC Makefile.libretro .
 crocods libretro-crocods https://github.com/libretro/libretro-crocods.git master YES GENERIC Makefile .
-desmume libretro-desmume https://github.com/libretro/desmume.git master YES GENERIC Makefile.libretro desmume
+desmume2015 libretro-desmume2015 https://github.com/libretro/desmume2015.git master YES GENERIC Makefile.libretro desmume
 dinothawr libretro-dinothawr https://github.com/libretro/Dinothawr.git master YES GENERIC Makefile .
 dolphin libretro-dolphin https://github.com/libretro/dolphin.git master YES GENERIC Makefile Source/Core/DolphinLibretro/
 dosbox libretro-dosbox https://github.com/libretro/dosbox-libretro.git master YES GENERIC Makefile.libretro .

recipes/emscripten/emscripten

@@ -3,7 +3,7 @@
 atari800 libretro-atari800 https://github.com/libretro/libretro-atari800.git master NO GENERIC Makefile .
 bluemsx libretro-bluemsx https://github.com/libretro/blueMSX-libretro.git master YES GENERIC Makefile.libretro .
 craft libretro-craft https://github.com/libretro/craft master YES GENERIC Makefile.libretro .
-desmume libretro-desmume https://github.com/libretro/desmume.git master NO GENERIC Makefile.libretro desmume
+desmume2015 libretro-desmume2015 https://github.com/libretro/desmume2015.git master NO GENERIC Makefile.libretro desmume
 dosbox libretro-dosbox https://github.com/libretro/dosbox-libretro.git master YES GENERIC Makefile.libretro .
 fbalpha2012 libretro-fbalpha2012 https://github.com/libretro/fbalpha2012.git master YES GENERIC makefile.libretro svn-current/trunk
 fbalpha2012_cps1 libretro-fbalpha2012_cps1 https://github.com/libretro/fbalpha2012_cps1.git master YES GENERIC makefile.libretro .

recipes/linux/cores-linux-armhf-generic

@@ -8,7 +8,7 @@ bsnes_cplusplus98 libretro-bsnes_cplusplus98 https://github.com/libretro/bsnes-l
 bsnes_mercury libretro-bsnes_mercury https://github.com/libretro/bsnes-mercury.git master YES GENERIC Makefile . | bsnes_mercury_accuracy:profile=accuracy bsnes_mercury_balanced:profile=balanced bsnes_mercury_performance:profile=performance
 cap32 libretro-cap32 https://github.com/libretro/libretro-cap32.git master YES GENERIC Makefile .
 chailove libretro-chailove https://github.com/libretro/libretro-chailove.git master YES GENERIC Makefile .
-desmume libretro-desmume https://github.com/libretro/desmume.git master YES GENERIC Makefile.libretro desmume platform=armv7-neon-hardfloat
+desmume2015 libretro-desmume2015 https://github.com/libretro/desmume2015.git master YES GENERIC Makefile.libretro desmume platform=armv7-neon-hardfloat
 dinothawr libretro-dinothawr https://github.com/libretro/Dinothawr.git master YES GENERIC Makefile .
 dosbox libretro-dosbox https://github.com/libretro/dosbox-libretro.git master YES GENERIC Makefile.libretro .
 emux libretro-emux https://github.com/libretro/emux master YES LEIRADEL Makefile libretro x86_64 | emux_chip8:MACHINE=chip8 emux_gb:MACHINE=gb emux_nes:MACHINE=nes emux_sms:MACHINE=sms

recipes/linux/cores-linux-x64-generic

@@ -13,7 +13,7 @@ chailove libretro-chailove https://github.com/libretro/libretro-chailove.git mas
 citra libretro-citra https://github.com/libretro/citra.git master YES CMAKE Makefile build -DENABLE_LIBRETRO=1 -DENABLE_SDL2=0 -DENABLE_QT=0 -DDISABLE_LIBPNG=1 -DCMAKE_BUILD_TYPE="Release" -DENABLE_WEB_SERVICE=0 --target citra_libretro
 craft libretro-craft https://github.com/libretro/craft master YES GENERIC Makefile.libretro .
 crocods libretro-crocods https://github.com/libretro/libretro-crocods.git master YES GENERIC Makefile .
-desmume libretro-desmume https://github.com/libretro/desmume.git master YES GENERIC Makefile.libretro desmume
+desmume2015 libretro-desmume2015 https://github.com/libretro/desmume2015.git master YES GENERIC Makefile.libretro desmume
 dinothawr libretro-dinothawr https://github.com/libretro/Dinothawr.git master YES GENERIC Makefile .
 dolphin libretro-dolphin https://github.com/libretro/dolphin.git master YES GENERIC Makefile Source/Core/DolphinLibretro/
 dosbox libretro-dosbox https://github.com/libretro/dosbox-libretro.git master YES GENERIC Makefile.libretro .

recipes/linux/cores-linux-x86-generic

@@ -11,7 +11,7 @@ craft libretro-craft https://github.com/libretro/craft master YES GENERIC Makefi
 crocods libretro-crocods https://github.com/libretro/libretro-crocods.git master YES GENERIC Makefile .
 cap32 libretro-cap32 https://github.com/libretro/libretro-cap32.git master YES GENERIC Makefile .
 chailove libretro-chailove https://github.com/libretro/libretro-chailove.git master YES GENERIC Makefile .
-desmume libretro-desmume https://github.com/libretro/desmume.git master YES GENERIC Makefile.libretro desmume
+desmume2015 libretro-desmume2015 https://github.com/libretro/desmume2015.git master YES GENERIC Makefile.libretro desmume
 dinothawr libretro-dinothawr https://github.com/libretro/Dinothawr.git master YES GENERIC Makefile .
 dosbox libretro-dosbox https://github.com/libretro/dosbox-libretro.git master YES GENERIC Makefile.libretro .
 easyrpg libretro-easyrpg https://github.com/libretro/easyrpg-libretro.git master YES GENERIC Makefile.libretro builds/libretro

recipes/playstation/ps3

@@ -1,7 +1,7 @@
 2048 libretro-2048 https://github.com/libretro/libretro-2048.git master NO GENERIC Makefile.libretro .
 atari800 libretro-atari800 https://github.com/libretro/libretro-atari800.git master YES GENERIC Makefile .
 bluemsx libretro-bluemsx https://github.com/libretro/blueMSX-libretro.git master NO GENERIC Makefile.libretro .
-desmume libretro-desmume https://github.com/libretro/desmume.git master NO GENERIC Makefile.libretro desmume
+desmume2015 libretro-desmume2015 https://github.com/libretro/desmume2015.git master NO GENERIC Makefile.libretro desmume
 dosbox libretro-dosbox https://github.com/libretro/dosbox-libretro.git master NO GENERIC Makefile.libretro .
 fbalpha2012 libretro-fbalpha2012 https://github.com/libretro/fbalpha2012.git master YES GENERIC makefile.libretro svn-current/trunk
 fbalpha2012_cps1 libretro-fbalpha2012_cps1 https://github.com/libretro/fbalpha2012_cps1.git master NO GENERIC makefile.libretro .

recipes/windows/cores-windows-x64_seh-generic

@@ -12,7 +12,7 @@ cap32 libretro-cap32 https://github.com/libretro/libretro-cap32.git master YES G
 chailove libretro-chailove https://github.com/libretro/libretro-chailove.git master YES GENERIC Makefile .
 craft libretro-craft https://github.com/libretro/craft master YES GENERIC Makefile.libretro .
 crocods libretro-crocods https://github.com/libretro/libretro-crocods.git master YES GENERIC Makefile .
-desmume libretro-desmume https://github.com/libretro/desmume.git master YES GENERIC Makefile.libretro desmume
+desmume2015 libretro-desmume2015 https://github.com/libretro/desmume2015.git master YES GENERIC Makefile.libretro desmume
 dinothawr libretro-dinothawr https://github.com/libretro/Dinothawr.git master YES GENERIC Makefile .
 dolphin libretro-dolphin https://github.com/libretro/dolphin.git master YES GENERIC Makefile Source/Core/DolphinLibretro/
 dosbox libretro-dosbox https://github.com/libretro/dosbox-libretro.git master YES GENERIC Makefile.libretro .

recipes/windows/cores-windows-x86_dw2-generic

@@ -12,7 +12,7 @@ cap32 libretro-cap32 https://github.com/libretro/libretro-cap32.git master YES G
 chailove libretro-chailove https://github.com/libretro/libretro-chailove.git master YES GENERIC Makefile .
 craft libretro-craft https://github.com/libretro/craft master YES GENERIC Makefile.libretro .
 crocods libretro-crocods https://github.com/libretro/libretro-crocods.git master YES GENERIC Makefile .
-desmume libretro-desmume https://github.com/libretro/desmume.git master YES GENERIC Makefile.libretro desmume
+desmume2015 libretro-desmume2015 https://github.com/libretro/desmume2015.git master YES GENERIC Makefile.libretro desmume
 dinothawr libretro-dinothawr https://github.com/libretro/Dinothawr.git master YES GENERIC Makefile .
 dosbox libretro-dosbox https://github.com/libretro/dosbox-libretro.git master YES GENERIC Makefile.libretro .
 easyrpg libretro-easyrpg https://github.com/libretro/easyrpg-libretro.git master YES GENERIC Makefile.libretro builds/libretro

rules.d/core-rules.sh

@@ -346,11 +346,11 @@ libretro_openlara_git_url="https://github.com/libretro/OpenLara.git"
 libretro_openlara_build_subdir="src/platform/libretro"
 libretro_openlara_build_makefile="Makefile"
 
-include_core_desmume() {
+include_core_desmume2015() {
-register_module core "desmume" -ngc -ps3 -psp1 -qnx -wii
+register_module core "desmume2015" -ngc -ps3 -psp1 -qnx -wii
 }
-libretro_desmume_name="DeSmuME"
+libretro_desmume_name="DeSmuME 2015"
-libretro_desmume_git_url="https://github.com/libretro/desmume.git"
+libretro_desmume_git_url="https://github.com/libretro/desmume2015.git"
 libretro_desmume_build_subdir="desmume"
 libretro_desmume_build_makefile="Makefile.libretro"
 
@@ -359,7 +359,7 @@ include_core_quicknes() {
 }
 libretro_quicknes_name="QuickNES"
 libretro_quicknes_git_url="https://github.com/libretro/QuickNES_Core.git"
-libretro_desmume_build_makefile="Makefile"
+libretro_quicknes_build_makefile="Makefile"
 
 include_core_nestopia() {
 	register_module core "nestopia"