Mac OS support for Utility::Directory::configurationDir()

[mosra]

Class Utility::Directory has various functions for dealing with filesystem and they are currently implemented for and tested on Linux and Windows only, as I don't have access to any Apple hardware where I could test that. Current implementation status:

• list() mkpath() and home() are POSIX-compatible and should just work
• rm() and move() should work for files, but I'm not sure about directories
• home() returns value HOME environment variable (also POSIX-compatible) and thus should work too
• configurationDir("App") currently returns ~/.config/app, which is not wanted. It should return some directory under ~/Library/ (the correct path is returned by some system API -- relevant SO thread).

[ytain]

For Mac OS X and iOS you need to use the CFBundleRef and use it to access your files that are saved within the app resource bundle, because of the sandboxing issue.

Here is the code example I use to access the files from within the Mac OS X app bundle (it uses a singleton class of my own, but you can ignore that):

macbundle.hpp

#include "CoreFoundation/CFBundle.h"

class MacBundle: public singleton<MacBundle>
{

private:
   CFBundleRef appBundle;

   bool initializeBundleLoading();
protected:
   MacBundle();

public:
   virtual ~MacBundle();

   friend class singleton<MacBundle>;

   std::string getFullPath(const std::string& filename);

};

---

macbundle.cpp

bool MacBundle::initializeBundleLoading()
{
   appBundle = CFBundleGetMainBundle();

   if(!appBundle)
   {
       return false;
   }
   return true;
}

MacBundle::MacBundle()
{
   initializeBundleLoading();
}

MacBundle::~MacBundle()
{

}

std::string MacBundle::getFullPath(const std::string& filename)
{
   if (!appBundle)
   {
       if (!initializeBundleLoading())
       {
           Debug() << "Failed to initialize the bundle!";
           return nullptr;
       }
   }

   CFURLRef resourceURL;

   // Look for the resource in the main bundle by name and type.
   resourceURL = CFBundleCopyResourceURL( appBundle, CFStringCreateWithCString( NULL, filename.c_str(), kCFStringEncodingASCII), NULL, NULL );

   if(!resourceURL)
   {
       Debug() << "Failed to locate a file in the loaded bundle!";
       return nullptr;
   }

   char *fileurl = new char[PATH_MAX];

   if(!CFURLGetFileSystemRepresentation( resourceURL, true, (UInt8*)fileurl, PATH_MAX))
   {
       delete[] fileurl;
       Debug() << "Failed to turn a bundle resource URL into a filesystem path representation!";
       return nullptr;
   }

   std::string str = std::string(fileurl);
   delete[] fileurl;

   return str;    
}

The same code would work with no difference on iOS as well.

[ytain]

Relevant Apple documentation on Bundles:

https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/Introduction/Introduction.html#//apple_ref/doc/uid/10000123i

In my code above that was written in C++, you can call the #include "CoreFoundation/CFBundle.h" to call the C structs/functions for CFBundle* stuff. No need to use ObjC or Swift code to get the relevant information.

[mosra]

Oh, thanks a lot for the code!

Speaking about this, I have access to Apple hardware now, so I can definitely look into this and fix it. Actually, I need something like this tomorrow :D

From my experience (though using Corrade in combination with SDL2 and Magnum) the normal filesystem calls were working just fine and opening say data/font.ttf properly located it in <bundle.app>/Contents/Resources/data/font.ttf. Seems that SDL2 is doing some magic with current working directory.

Another thing: would _NSGetExecutablePath() do the trick too? Or is there any downside to that approach?

[ytain]

The issue is sandboxing. You have very limited places where you can download and save your own stuff, except the access of files from within the bundles.

If you try to access outside the limits imposed by the sandboxing, you get failures like user permissions needed etc.

https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AboutAppSandbox/AboutAppSandbox.html

Also look there for the C functions:
CFBundleCopyExecutableURL

http://opensource.apple.com//source/CF/CF-550/CFBundle.h

It has also additional functions allowing you to load the plugins dynamically like those CFBundleLoadExecutable and CFBundleUnloadExecutable etc.

[ytain]

Also if you see in Apple documentation the requirement to use ObjC functions, you can use associated CF functions like: NSHomeDirectory is equivalent to CFCopyHomeDirectoryURL ( http://stackoverflow.com/a/12717548 )

A solution for creating temporary files: http://stackoverflow.com/a/12714258

Also kinda incomplete C++ wrapper for CoreFoundation:
https://github.com/macmade/CFPP

Thinking more about the sandboxing, I think we are forced to use some ObjC++ to use some specific Core Foundation functions that are not available as C functions to be called from C code.

[mosra]

OSX/iOS sandbox support for Directory::configurationDir() and Directory::home() is in 5d58f4b. In the end it was enough to use the HOME environment variable, so fortunately I have common code for all Unix-like platforms. Added also Directory::executableLocation() in d6f38db which points to the location where the executable is. Apart from Linux and Windows support I used _NSGetExecutablePath() for both non-sandboxed OSX and sandboxed OSX/iOS to avoid the need to link to CoreFoundation framework. There is now also Directory::isSandboxed() utility function.

Opened a new issue #23 to track dynamic plugin support on iOS.

Thanks a lot for the very detailed help!