macOS : wrong current directory when launched from command line

[cgimenez]

I've build oricutron from command line (with a simple make, not Xcode) What I got is a simple terminal app (not an OSX application), so far so good.

Unfortunately when oricutron starts, it sets the current directory 3 levels upper the current one making the -t flag unusable. The offending code is around is https://github.com/pete-gordon/oricutron/blob/9e4e3ca32c3c3f33246555953cd241c55e9d2b78/main.c#L1629 Commenting the chdir() solves the problem, and oricutron happily cload the selected tape file at startup.

Dunno if there's a way to detect if the code is being build with Xcode (maybe a known Xcode define) or not.

[rampa069]

try:

make osx-package

This will make an app with all the needed resources inside

[cgimenez]

Tried and got :

Host OS         : osx
Target platform : osx
Using SDL lib   : sdl
Using SDL prefix:
make: *** No rule to make target `osx-package'.  Stop.

[iss000]

Try: make PLATFORM=osx package-osx

Also you can try this code snipped replacing the one around 'chdir':

    // ----------------------------------------------------------------------------
    // This makes relative paths work in C++ in Xcode by changing directory to the Resources folder inside the .app bundle
#ifdef __APPLE__
    CFBundleRef mainBundle = CFBundleGetMainBundle();
    CFURLRef resourcesURL = CFBundleCopyResourcesDirectoryURL(mainBundle);
    char path[PATH_MAX];
    if (CFURLGetFileSystemRepresentation(resourcesURL, TRUE, (UInt8 *)path, PATH_MAX))
    {
        // this directory is something/Oricutron.app/Contents/Resources
        // go down 3 times to find the app containing directory
        strcat(path, "/../../..");
        chdir(path);
    }
    CFRelease(resourcesURL);
    //printf("Current Path: %s\n", path);
#endif

Please, give feedback of results.

[cgimenez]

make clean
make PLATFORM=osx package-osx
Host OS         : osx
Target platform : osx
Using SDL lib   : sdl
Using SDL prefix:
mkdir -p Oricutron_osx_v12/Oricutron.app/Contents/MacOS
mkdir -p Oricutron_osx_v12/Oricutron.app/Contents/Resources/images
mkdir -p Oricutron_osx_v12/Oricutron.app/Contents/Resources/roms
install -m 755 oricutron Oricutron_osx_v12/Oricutron.app/Contents/MacOS/Oricutron
install: oricutron: No such file or directory
make: *** [package-osx] Error 71

[cgimenez]

But the snippet solves the problem !

[iss000]

Great! I'll commit the change. During next weekend will check what's wrong with the osx build.

[cgimenez]

About make PLATFORM=osx package-osx

macOS app is built under the Oricutron_osx_v12 directory, but when launching from the desktop (app in the same place, didn't tried from the Applications directory) :

Feb 11 10:02:53 MBPro com.apple.xpc.launchd[1] (Oricutron.28412[1684]): Service exited with abnormal code: 1

If I remember well I've got the same problem with macOS version from http://www.petergordon.org.uk/oricutron/

I'm under macOS 10.15.7 and I see this diagnostic message :

com.apple.message.domain: com.apple.graphics.clients
com.apple.message.__source__: SPI
com.apple.message.architecture: 64
com.apple.message.context_type: Metal
com.apple.message.signature2: 1.2
com.apple.message.signature3: Metal
com.apple.message.signature1: Oricutron
com.apple.message.summarize: YES
com.apple.message.intermediate_frameworks: libSDL2-2.0.0.dylib,libSDL-1.2.0.dylib,Direct,CoreFoundation,Foundation,AppKit,AE,HIToolbox
SenderMachUUID: E350F6AC-2910-3D04-8DDC-773395B96271

[cgimenez]

And the 3 steps up levels problem is back :-(

The code snippet worked, but then https://github.com/pete-gordon/oricutron/commit/2e3f760c460cfe0c4ec365d5df20945bead8bba0 negated (on purpose I presume) the CFURLGetFileSystemRepresentation() call, which cause the chdir(path) to execute and BAAM!, wrong dir for tapes and disks

[erik-persson]

If nobody else is working on this presently, I'm happy to pick this up, I have visibility of this as I move back and forth between Linux and macOS. I was thinking there could be 3 components to a solution.

1. To facilitate for Linux users who only briefly visit macOS, we could let the "make && ./oricutron" usage model work on macOS too, by extending the code for finding the program directory to deal with the non-bundled case.

2. To make oricutron -t work on macOS, we could hold back on the cd'ing in the main function that makes macOS stand out currently, but keep the calculated path in a next step.

3. To find resources in a Mac app bundle (without breaking -t ) we could adjust how file paths are produced in gui.c and main.c. Platforms currently control where resources are found using the constants FILEPREFIX, ROMPREFIX and IMAGEPREFIX (e.g. Amiga sets ROMPREFIX set to "PROGDIR:roms/" to steer towards the program binary's directory). The constants are concatenated to file names in gui.c and main.c, currently at compile-time e.g. IMAGEPREFIX"tape_ejected.bmp". We could change this to run-time concatenation, and the macOS may then inject a variable path similar to the path chdir'd to in main() presently.

Happy to hear your feedback on this.