1a30a6a1a1
What (should) work): - LIBRETRO_DEVELOPER (default 1) to output all build progress - LIBRETRO_LOG_DIR (default $WORKDIR/log) to change WHERE logs get written. Useful for buildbots that have multiple WORKDIRs to put logs in roughly the same place. - LIBRETRO_LOG_SUPER (default libretro-super.log) to change the name of libretro-build.sh's log file. No log would be written if unset, but script-modules/log.sh sets it if unset for now. - LIBRETRO_LOG_CORE (default %s.log) to change the name pattern for a core log file. The %s is replaced with the "safe" core name used by libretro-super's rules. - LIBRETRO_LOG_APPEND (default ""), if set, would not clobber the log files the next time you ran libretro-super. Caution: mame's output is 34 megabytes on its own for a single successful build What doesn't work yet: - You should be able to unset LIBRETRO_LOG_SUPER and LIBRETRO_LOG_CORE and have your decision mean something. This is the #1 thing I must change, and I will do so in the next day or so. - We assume that if you want output to screen and log, you'll have the tee command. What if you don't? We choose log over screen in that case, but tee is such a trivial tool to implement, perhaps we should? - Currently logs lack date stamps. Bash's built-in printf has a way to do this, but Apple STUPIDLY disables it because Apple. Turns out that bash 2.05a didn't have the feature anyway. You may not have the UNIX date command on Windows if you're somehow running bash from cmd.exe. Worse, you have a command of the same name that requires a /t argument to do half of what date does on UNIX. Running into limits of bash here, easily solved using most anything else. |
||
|---|---|---|
| dist/info | ||
| docs | ||
| recipes | ||
| rules.d | ||
| script-modules | ||
| .gitignore | ||
| libretro-build-android-mk.sh | ||
| libretro-build-common-gx.sh | ||
| libretro-build-common-xdk.sh | ||
| libretro-build-common.sh | ||
| libretro-build-database.sh | ||
| libretro-build-ios-theos.sh | ||
| libretro-build-ios.sh | ||
| libretro-build-ngc.sh | ||
| libretro-build-ps3.sh | ||
| libretro-build-psp1.sh | ||
| libretro-build-qnx.sh | ||
| libretro-build-wii.sh | ||
| libretro-build-win.sh | ||
| libretro-build-xdk1.sh | ||
| libretro-build-xdk360.sh | ||
| libretro-build.sh | ||
| libretro-buildbot-recipe.sh | ||
| libretro-buildbot-task.sh | ||
| libretro-config.sh | ||
| libretro-fetch.sh | ||
| libretro-header-update.sh | ||
| libretro-install.sh | ||
| libretro-upgrade.sh | ||
| radius-buildbot | ||
| retroarch-build.sh | ||
| retrolink.sh | ||
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 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 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 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:
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-superorcd ~/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.