diff --git a/docs/README.MacOSX.md b/docs/README.MacOSX.md deleted file mode 100644 index 3dda5b2b..00000000 --- a/docs/README.MacOSX.md +++ /dev/null @@ -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. - - - - -# 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. - - diff --git a/docs/devel/README.iKarith.md b/docs/devel/README.iKarith.md deleted file mode 100644 index 32eaccc7..00000000 --- a/docs/devel/README.iKarith.md +++ /dev/null @@ -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. - - - diff --git a/recipes/android/cores-android-jni b/recipes/android/cores-android-jni index 62aa7d04..e386969a 100644 --- a/recipes/android/cores-android-jni +++ b/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 diff --git a/recipes/android/cores-android-jni-aarch64 b/recipes/android/cores-android-jni-aarch64 index 86cbbc6f..adf9585f 100644 --- a/recipes/android/cores-android-jni-aarch64 +++ b/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 diff --git a/recipes/apple/cores-ios-generic b/recipes/apple/cores-ios-generic index 9fe443b8..1f46a167 100644 --- a/recipes/apple/cores-ios-generic +++ b/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 diff --git a/recipes/apple/cores-ios9-generic b/recipes/apple/cores-ios9-generic index e1ae30b5..b31dfc7b 100644 --- a/recipes/apple/cores-ios9-generic +++ b/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 diff --git a/recipes/apple/cores-osx-x64-generic b/recipes/apple/cores-osx-x64-generic index af24fec0..6a02ea46 100644 --- a/recipes/apple/cores-osx-x64-generic +++ b/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 . diff --git a/recipes/emscripten/emscripten b/recipes/emscripten/emscripten index 292d3e1d..34c5e903 100644 --- a/recipes/emscripten/emscripten +++ b/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 . diff --git a/recipes/linux/cores-linux-armhf-generic b/recipes/linux/cores-linux-armhf-generic index 197c3a72..db8961a1 100644 --- a/recipes/linux/cores-linux-armhf-generic +++ b/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 diff --git a/recipes/linux/cores-linux-x64-generic b/recipes/linux/cores-linux-x64-generic index ea2befd2..c3c5eb9e 100644 --- a/recipes/linux/cores-linux-x64-generic +++ b/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 . diff --git a/recipes/linux/cores-linux-x86-generic b/recipes/linux/cores-linux-x86-generic index f8728351..132268e7 100644 --- a/recipes/linux/cores-linux-x86-generic +++ b/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 diff --git a/recipes/playstation/ps3 b/recipes/playstation/ps3 index 3ad72a1c..de73575c 100644 --- a/recipes/playstation/ps3 +++ b/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 . diff --git a/recipes/windows/cores-windows-x64_seh-generic b/recipes/windows/cores-windows-x64_seh-generic index 947a5715..98f176b1 100644 --- a/recipes/windows/cores-windows-x64_seh-generic +++ b/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 . diff --git a/recipes/windows/cores-windows-x86_dw2-generic b/recipes/windows/cores-windows-x86_dw2-generic index ae37355c..29892e59 100644 --- a/recipes/windows/cores-windows-x86_dw2-generic +++ b/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 diff --git a/rules.d/core-rules.sh b/rules.d/core-rules.sh index 214e90c7..ae36bc4a 100644 --- a/rules.d/core-rules.sh +++ b/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() { -register_module core "desmume" -ngc -ps3 -psp1 -qnx -wii +include_core_desmume2015() { +register_module core "desmume2015" -ngc -ps3 -psp1 -qnx -wii } -libretro_desmume_name="DeSmuME" -libretro_desmume_git_url="https://github.com/libretro/desmume.git" +libretro_desmume_name="DeSmuME 2015" +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"