OS X CLI Support?

RetroArch Apple devices
#1

I had been using an old OS X build for a while and decided to download a new one. What I found is that RetroArch is distributed in a native .app form now rather than a cli binary.

Before, I was able to launch roms via the command line passing the right options to the binary. This let me launch RetroArch on top of other things and was really great for doing things like HTPC and full screen Frontend stuff.

I tried doing it with a 1.0.0.2 build but nothing seemed to work right. I coulnd’t even run --help on it :frowning: I tried it on the binary inside of /Contents/MacOs.

Has this changed? Is there no more command line binary? Am I doing it wrong? Can I do an optional build of RetroArch to get this type of binary back?

Let me know if I’m clueless, out of luck, or what I should be doing differently. Thanks!

#2

Yeah, it’s a native app now, rather than the path-of-least-resistance-from-linux port that it used to be. However, you should still be able to compile the *nix-style using macports, I would think. I haven’t tried it, myself, though, so let us know if you run into problems. You may have to get an old makefile from before the changeover…

If you’re not on top of compiling your own binaries, etc. I can try to take a look at it soon, possibly this evening.

#3

Yeah, it’s a native app now, rather than the path-of-least-resistance-from-linux port that it used to be.

This makes me sad :frowning: The fact that you could launch roms via the console is what attracted me to RetroArch (oh and its core based support of 1000000 things, heh). Basically no emulators support this on the Mac. To move away from it takes a lot of what made it special on OS X.

RetroArch believes in modularity. The application itself is a command-line driven application suitable for HTPC and/or headless use.

I always loved this on the main page for RetroArch.

It’d be awesome if there was just a way to do an OS X build that created the old style binary to keep RetroArch useful for these types of things. I’ll create an issue on the repo.

#4

CLI being broken is bad. Looking here https://github.com/libretro/RetroArch/b … platform.m, it might be possible to place your arguments after two – … Not sure what the purpose for that is though, but worth a try.

#5

Take this up with Apple. It does not want anything to do with the commandline.

http://stackoverflow.com/questions/1308 … mmand-line

Instead, applications are encouraged to support Apple Events. You can do things like ROM loading by dragging a ROM (or any other content) over the dock app icon (when this event is properly implemented). It can also be used with Apple’s Automater tools. I’ll make sure most of the important Apple Events are supported later on.

What you could try is specifying the binary inside the .app bundle with ‘open’ and seeing if you can pass commands to it that way.

The plain-jane port might well have been ‘unique’, but I don’t think being ‘unique’ on a platform that is all abouet conformance is a really good idea. The OSX port before was terribly out of place in comparison to other OSX apps and it put us in a very bad position to actually build a decent userbase. The new version shares a lot of common code with the iOS port and performance-wise it’s great - plus it has better backwards compatibility than something like OpenEmu (goes back to at least 10.6 Snow Leopard, and I’m trying to make it 10.5 compatible right now as well for my iBook G4). So I think there is a lot to recommend it there. I don’t put my eggs in the OpenEmu basket anyway since it doesn’t have a real libretro player implementation and it doesn’t have the kind of backwards compatibility that I need anyway. So we needed a really solid OSX version for RetroArch. And it also has things now like CoreLocation support (for the location API) - due to be expanded soon with CoreVideo support or whatever the camera API is called.

And I don’t really like the OpenEmu comparisons anyway - it really sounds like people are strongarming other projects into not putting in a solid effort on the OSX front just because of that thing. RetroArch is not going to be only about emulation and I don’t consider RetroArch to have any competitors the direction I’m going with it - at all. So just going ‘let’s make it ultra-niche’ for the sake of it is dumb - and that is what that plain-jane port would guarantee in terms of userbase. You simply can’t have a ‘command-line driven’ program on OSX if you don’t want to get laughed out of the room by those Mac users - and it’s been a long time since RetroArch was predominantly about the commandline anyway (on that note, I’d hope the text on Themaister’s Den gets redirected to a simple link to libretro.com and instead we write some better explanation about what RetroArch and libretro is about instead of the kind of ‘nonsense’ talk on libretro.com right now about it being a ‘powerful engine’ - ye, I know that is my fault - I tried to make it more ‘accessible’ in terms of language to people but it really looks disingenuous anyway so I guess we have to be more factual in terms of explanation without totally dumbing it down like that).

Also, what I like about the new port is that it has zero dependencies. Contrast this with the old version that relied on a shitload of dependencies from Macports (goddamn does that thing hog a lot of harddrive space - 30 to 40GB wasted is no exaggeration), then Nvidia’s Cg toolkit (deprecated now anyway). The average noob would have no idea what to do with it really. On the other hand, everybody knows how to compile stuff from Xcode.

Overall, I think it’s infinitely superior to what came before.

#6

Doesn’t look like you can append commandline switches to a binary inside an app bundle. Already tried it with both ‘open’ and without and it doesn’t really respond.

So the best we can do is just supporting as many Apple Events as possible - then maybe you could fall back on something like Automator to do the scripting with instead for your frontend.

Apple just seems to not care one iota about commandline usage these days - so given that this tries to be a ‘native’ port, I think it’s best if we don’t care for this platform either if the platform holder can’t bother to care about it either.