Re: Android: How to call GSInitializeProcess() properly?

[Richard Frith-Macdonald]

On 12 Jun 2014, at 11:27, Ivan Vučica <ivan@vucica.net> wrote:

> Hi,
> 
> as you may know, any native code in Android GUI applications must be 
> delivered as a shared object.
> 
> So, there is no main() and there is no executable. There is also no bundle 
> that the binary can be delivered in, and we might only fake HOME by providing 
> the application's data directory. (I temporarily use /.)
> 
> Based on previous discussions on this list, I've thrown together a fake call 
> to GSInitializeProcess():
> 
>     const char* argv[1] = { "gnustep-app" };
>     const char* env[3] = { "USER=android", "HOME=/", NULL };
>     GSInitializeProcess(1, argv, env);
> 
> Sadly:
> 
>     I/gnustep-app( 6739): 2014-06-12 10:25:35.191 gnustep-app[6739] 
> NSBundle.m:396  Assertion failed in NSString *GSPrivateExecutablePath().  
> NSInternalInconsistencyException
> 
> Any existing approach to dealing with there-is-no-executable situation?

I don't know of any (and would be surprised if anyone has done it).

The GSPrivateExecutablePath() function to locate the running executable is key 
to finding relative/relocatable configuration information (GNUstep.conf) and 
therefore finding where the program is installed and hence where/how to handle 
the parts of the OpenStep/Cocoa API dealing with file/resource locations.

So ... I imagine we actually need specific new code in base to handle this for 
android.
I don't know the android APIs at all but I do know (from using a phone and 
reading a bit) that.
1. apps normally store their data on the internal phone memory, but can usualy 
be moved to the sd card
2. in the latest android release, the app data on the sd card is forced to live 
in a fixed folder location

That suggests to me that android must provide an api for determining what 
folder the app and its data lives in ... so I guess GSPrivateExecutablePath() 
would need to be modified to point to a dummy/fake executable within that 
folder, and anything using it would need to be modified to cope with the fact 
that the executable itsself might not actually be there; probably little to do 
since I guess mostly code will likely just remove the last path component (the 
name of the executable) and use the remainder as a starting point to find 
resources.
The base library could then be configured with default relative paths (from 
GNUstep.conf) and would locate resources using those relative paths.

On the other hand, it might make more sense to change all the bundle/path 
utilities code to use the corresponing android APIs (probably a lot more work 
though).