Re: globally installed packages vs. relocatable Octave

[Ben Abbott]

> On Nov 7, 2014, at 4:14 AM, c. <address@hidden> wrote:
> 
> 
> On 6 Nov 2014, at 19:25, John W. Eaton <address@hidden> wrote:
> 
>> Is it necessary to allow the global prefix to be modified, or would it
>> be OK to simply expect that globally installed packages are located in
>> a directory under OCTAVE_HOME? 
> 
> I am not sure that would work if we intend to make a relocatable .app
> bundle for OSX.
> 
> an app bundle is just a folder you can move around where you like through
> the finder GUI which contains all executables, libraries and data files
> required for the application to run.
> 
> How would you change the value of OCTAVE_HOME when the the bundle is moved?
> 
> c.

App bundles under OSX are self contained and rellocatable by making use of 
@executable_path, @loader_path, and @rpath in the executable and in the libs.

https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/dyld.1.html.

In the App bundle, I used a clumsy script that evolved over several years 
(Kienzle, Treichl, & then me). The last copy I used is attached. Some shell 
script magic was used to derive OCTAVE_HOME and then used to rebased several 
environment variables to allow Octave to run and mkoctfile to function.

Deriving OCTAVE_HOME is rather simple.

if [ -L "$0" ] ; then
 ROOT="$(dirname $(readlink -n "$0"))"
else
 ROOT="$(cd "$(dirname "$0")" 2>/dev/null && pwd)"
fi
OCTAVE_HOME ="$(dirname "${ROOT}")"

However, setting the many other environment variables was the clumsy part (for 
me), and prone to errors. This is particularly true with octave-config (needed 
to allow mkoctfile to function).

Ben

octave
Description: Binary data