(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.
- 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
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-
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
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:
Rem Start Octave (this detaches octave-gui and immediately
Rem ( or: start octave-3.9.0+.exe )
Rem Close the batch file's cmd32.exe window
(watch out for line breaks)
Until now this setup works quite satisfactorily for me.
- 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.
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
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
First of all, I'd like to emphasize that this joke is pimarily meant to simplify and speed up development of Octave on Windows esp. when cross-building.
Some simple makefile patches are on the tracker now (see https://savannah.gnu.org/patch/?8469)
Batch files to start Octave are included there as well.
A little issue is ghostscript; I've added my own installation in the PATH command in the batch file so that has to be amended.
I looked into somehow including a ghostscript installer in mxe but didn't get much progress.
I remember from last year JWE's comment that ghostscript was still problematic. AFAICS that could be because the ghostscript web site only releases binary installers and no zipped archives; with windows archive tools those binary installers are easily unzipped, but not so with msys/mingw tools. And maybe the Affero GPL license is insufficiently compatible?
Anyway, I've experimented with 3.8.1, 3.9.0+ and 4.1.0+ in one installer, and that generally works well.
Later I decided to throw out 3.8.1 as it isn't fully binary compatible with 3.9.0+ onward; a notable symptom is that the OF windows package installed in 3.8.1 doesn't work in 3.9.0+ & up, and vice versa - something with the generated .oct files not recognized by the loader. 3.9.0+ and 4.1.0+ are fully compatible.
A full 3.8.1/3.9.0+/4.1.0+ installation on Windows requires ~950 MB (1.07 GB after all included OF packages have been built & installed). Comparing that to three times an average single-version mxe installer (~750 MB) I see a fair amount of disk space saving.
A next step would be to just generate the <mxe-octave>/octave tree (that is, the octave/..../i686-w64-mingw32 part) and "install" that over an existing Octave-Windows installation.
After all it's just the Octave files that get updated, the dependencies and rest of the msys/mingw setup won't change much - if you don't update the mxe tree too often, of course. E.g., my current mxe setup was updated for the last time some 5 weeks ago. That would save a significant amount of time, i.e. copying over and stripping all the dependencies, generating the nsis script and generating the installer or zip file. Not to mention copying over and installing in Windows.
(Cross-) Building octave can invoke all CPU cores, the rest can only be done in one thread It is only the former (building Octave) that is needed by Windows developers, once an mxe installation is in place on the Windows side.
BTW I just finished an installer for today's (May 25) 3.9.0+-4.1.0+ "snapshots". Any objection to put it up on e.g., my dropbox?
That would allow a broader audience to try out the development versions on Windows, instead of initially just on Linux (out of reach for many Windows users) and only later on, after release and when an installer has been made, on Windows.
|Free forum by Nabble||Edit this page|