Relocatable octave

[Paul Kienzle]

Context: We would like to construct an octave.app application which 
acts like I normal macintosh application.  To do this we need to be 
able to run octave no matter where it is installed.

On May 28, 2007, at 4:46 AM, Thomas Treichl wrote:

> a) In the liboctave.dylib the octave_config_info informations eg.
>
>   octave:1> octave_config_info ('bindir')
>
> are hardcoded, ie. if a octave function uses one of this informations 
> then it may fail because of a path that points into my temporary 
> install directory. I used sed to replace these paths but then 
> liboctave.dylib is destroyed.

I agree that you don't want to modify liboctave.dylib using sed.

> The most biggest problem is that the function mkoctfile doesn't work 
> anymore (1st because of the directory information 'bindir'

On startup octave sets the PATH environment variable, including the 
bindir configure information.  You can override this path from the 
command line by setting OCTAVE_EXEC_PATH before running octave.

mkoctfile.m should respect the OCTAVE_EXEC_PATH and not hardcode the 
full path to mkoctfile in bindir.  The following in 
miscellaneous/mkoctfile.m:

  shell_script = fullfile (bindir, sprintf ("mkoctfile-%s", 
OCTAVE_VERSION));

should be changed to:

  shell_script = sprintf ("mkoctfile-%s", OCTAVE_VERSION);

Looking at the set_exec_path function in src/defaults.cc, the contents 
of OCTAVE_EXEC_PATH are included on the path before anything else, so 
the correct version of mkoctfile should be picked up by the system 
command.

Confirm that this works before sending a patch to address@hidden

Looking through my mkoctfile shell script I see:

: ${INCFLAGS="-I/usr/local/include/octave-2.9.9 
-I/usr/local/include/octave-2.9.9/octave -I/usr/local/include"}
: ${DL_LDFLAGS="-bundle -bundle_loader /usr/local/bin/octave-2.9.9"}
: ${LFLAGS="-L/usr/local/lib/octave-2.9.9"}

You can set these variables correctly by hand before you start octave 
in you octave.app script.  Then when octave calls mkoctfile it will use 
the values from your environment.  E.g.,

Avocado:~/cvs/octave paulkienzle$ INCFLAGS=hello mkoctfile -p INCFLAGS
hello


>  and 2nd because other users must not have installed the same macports 
> compilers than me - this would mean that the mkoctfile shell script 
> must be changed by hand). Shipping the same compilers with the 
> octave.dmg wouldn't make sense, because then the octave.dmg grows from 
> 70MB to > 200MB.

This problem is more difficult.  I'm hoping you can use the default 
C/C++ compiler and just ship your own version of the fortran compiler.

You will of course have to override the fortran flags given by FLIBS in 
mkoctfile:

: ${FLIBS="-L/usr/local/lib/gcc/powerpc-apple-darwin8.8.0/4.2.0 
-L/usr/local/lib/gcc/powerpc-apple-darwin8.8.0/4.2.0/../../.. -lz -lm 
-lgfortranbegin -lgfortran -lSystemStubs"}

The same technique as above should work, though different versions of 
the fortran compiler may need different flags.

The fat-binary fortran compiler at:

   http://r.research.att.com/tools/

ships in a 16 Mb dmg.  This is a little more palatable than the 130 Mb 
for the whole tool chain, but it would be nice if Apple would just ship 
the compiler themselves.

We may decide to ship the fortran compiler separately, so users will 
not be able to install fortran-based packages until the first install 
the compiler.  For octave-forge, that excludes the spline and ode 
packages.

> b) Not having a working mkoctfile makes it impossible to install most 
> pkgs from octave-forge. So I had the idea to install the latest forge 
> in the octave.app. As ./configure --prefix=somewhere && make && make 
> install doesn't work anymore because of the pkg system this has to be 
> done manually from another second installed octave and must then 
> manually be copied into the octave.app.

Not sure if this will still be a problem.

> So this is a point that makes it really hard. I don't know if it would 
> make sense to install it that way and remove the mkoctfile features 
> from the octave.app. But this would mean that we can just create 
> somekind of 'beginner's version' of octave.app - the user wouldn't be 
> able to use the DYLD features at runtime ...

Hopefully the above magic fixes the mkoctfile problems. The octave-mac 
ecosystem will be much healthier if users can download and build their 
own packages, and easier to maintain too.


        - Paul