Re: Relocatable octave

[Thomas Treichl]

Paul Kienzle schrieb:
> > 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);

I did tests with this and found out that this change would be necessary, 
otherwise some package installations do fail. So meanwhile I'm trying to patch 
mkoctfile.m before calling ./configure as long as we can say that such a change 
can be added to the octave sources (or not).

> 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"}

I used some similar variables now with the startup script:

  OCTINCLUDEDIR=${1}/Contents/Resources/include/octave-2.9.12
  INCLUDEDIR=${1}/Contents/Resources/include
  OCTLIBDIR=${1}/Contents/Resources/lib/octave-2.9.12

Works perfectly ;)

> >  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.

I can use the default gcc now and gfortran from the link you've sent. Together 
they are doing a good job. I actually don't want to ship just a gfortran with 
the octave.app but further tell the users where to get that one needed in a 
seperate *html file.

> 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"}

If the user installs the one fortran compiler that is used for building the 
octave.app then I think nothing has to be changed here.

> 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.

No problem anymore - all packages have installed fine ;)

> > 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

Ok, let me clean up codes the following days - then you should have a closer 
look at them. After that we post them once again on the maintainer's list and 
see how we can continue.

Comment from Michael: 'I don't know if this is very relevant, but I had a 
similar problem with Win32 version of octave. This has been solved by additional 
substitution, see toplev.cc and sysdep.cc (w32_set_octave_home): the idea is to 
define OCTAVE_HOME automatically at startup.'

Yes this is relevant, great thanks for your help. Something similar is done for 
starting up the Mac octave.app ;)

- Thomas