Multiple Octave versions in one MXE-Octave installer

[Philip Nienhuis]

(The below is a work in progress. As I won't have much time until 
mid-May and I don't know if other people deem it worthwile, I just 
report about a few initial steps.)

Some months ago I started experiments with integrating multiple Octave 
versions into one and the same MXE installer. As the MXE installer more 
or less puts a mini *nix-system in place, and multiple Octave versions 
can coexist peacefully on plain *nix, I figured this should be a piece 
of cake on Windows as well.
Other motives:

- Conserving some disk space (an mxe-octave built binary installation is 
about 750+ MB, Octave itself is altogether a mere 95+ MB)

- Easier testing of OF packages across multiple Octave versions (in 
/share/ (/usr/local/share) and in /lib/ (/usr/local/lib) there's one O-F 
package dir for multiple Octave versions)

- (Maybe in the future)  Preparations / Options for lightweight 
installers that just add or upgrade only a new Octave version itself 
into an existing mxe-octave installation. Looks ideally suited for 
development versions - it would save lots of waiting time before a patch 
can be tested.
BTW: this isn't only suited for multiple-octave installations; in 
principle it could be done right now as well.


I also figured it would be preferrable to start Octave through batch 
files rather than through direct "shortcuts" to the executables, because:

- This provides a great way to avoid clobbered up Windows PATHs (the 
ones polluted with all kinds of junk SW interfering with Octave's execution)

- It makes it fairly easy to separate multiple Octave versions installed 
in one and the same mxe-octave directory (see below).


I didn't yet dive into the makefiles, first I wanted to check if my idea 
would work at all. So it invoked a bit of manual intervention in the 
mxe-octave build chain (i.e., on my Linux build box), as follows:

After more or less "normally" building each Octave version, I made 
subdirs in the <mxe-octave>/usr/..../i686-w64-mingw32/bin directory 
(actually there are two; why?) named after the Octave version: currently 
3.8.1, 3.9.0+, and 4.1.0+.
Once installed on Windows, all "versioned" Octave executables except 
octave-gui.exe can still live in /bin so I left them in place; in the 
abovementioned subdirs (e.g., 3.9.0+) I've moved octave-gui.exe, 
octave.exe, octave-cli.exe, mkoctfile.exe, octave_config_info.exe plus 
the octave .dll files liboctave-2.dll, liboctgui-0.dll, and 
liboctinterp-2.dll.
A few more steps are required (e.g., manually cleaning up the last built 
Octave version executables after installation on the Windows side).
Obviously, as soon as makefiles are adapted all of this gets easier.


Next thing was to set up the batch files required to start a particular 
Octave version. Until now I've done this only after installation on the 
Windows side, but a template like below could be included in the 
mxe-octave build tree as well.
Assuming such a batch file is ending up in Octave's installation "root" 
directory, a typical example looks as follows (for -in this example- 
3.9.0+):

-------------------cut----------------------
@echo off
   Rem   Find Octave's install directory through cmd32.exe variables.
   Rem   This trick finds the location where the batch file resides.
   Rem   Note: the result ends with a backslash

set OCT_HOME=%~dp0

   Rem   Set up PATH. Make sure the Octave-version-specific subdir
   Rem   comes first. Use system environment variables for the
   Rem   Windows system dirs.
   Rem   Ghostscript is still an issue, I've left my setup for it
   Rem   in the line below:

set 
PATH=%OCT_HOME%bin\3.9.0+;%OCT_HOME%bin;%windir%\system32;%windir%;%windir%\system32\wbem;C:\Programs\gs\gs9.04\bin

   Rem   Start Octave (this detaches octave-gui and immediately
   Rem   returns):

start octave-gui.exe
   Rem ( or:  start octave-3.9.0+.exe )

   Rem   Close the batch file's cmd32.exe window

exit
-------------------cut----------------------
(watch out for line breaks)

Until now this setup works quite satisfactorily for me.


Future steps:

- Modifying the various MXE makefiles to put the Octave .dll and .exe 
files and octave-gui.exe in the proper subdirs

- (Perhaps) Adapting the makefile to accept an Octave version rather 
than "stable-octave" or "octave"

- Modifying the NSIS install script to mimic the location of the executables

- Modifying the NSIS install script to invoke the "versioned" 
executables ("octave-3.9.0+.exe") rather than the unversioned ones 
("octave.exe"). After all, they're verbatim copies of each other (there 
are no symlinks on Windows)

- A make option to provide an Octave-binaries-only installer for 
upgrading an existing mxe-octave installation.

- In addition I suppose the location of the docs should be amended to 
match Start Menu shortcuts to a particular Octave version.


Some remarks:

It might be nice if the octave-gui.exe executable could be "versioned" 
as well. If it were, perhaps only the Octave .dll files would need to be 
moved into the version-dependent subdir. Maybe even the dlls can be 
versioned?
Yet the layout outlined above does work quite well.

Alternatively, in principle octave-gui.exe could just stay in 
/libexec/octave/<version>/exec/<arch>, and the Octave .dll files could 
be moved there as well. In the batch file this subdir could then be put 
first in the path rather than a <version> subdir of /bin.
I did some experiments with this, but with little luck: Octave would 
start, but its search path would contain just "." Maybe this is due to 
the (hard-coded? / prefix) mechanism invoked by Octave to find its 
components?

Philip