[Octave-bug-tracker] [bug #44338] test __osmesa_print__.cc-tst fails in MXE-octave

[Philip Nienhuis]

Follow-up Comment #10, bug #44338 (project octave):

What "tips" section, Mike? (comment #8)

As to comment #7:

Leaving debug symbols in is as easy as changing the line (in the top of the
mxe-octave Makefile)
 
STRIP_DIST_FILES := yes

into

STRIP_DIST_FILES := no

Remember, making a binary nsis-installer (.exe) gets tricky then as the total
size of all files may be > 2 GB = out of NSIS' capabilities, so only a zipdist
(or is it zip-dist?) (.zip) may be possible.

My build boxes are multi-boot systems in which I can access ("mount") the
Linux /home drive directly from within Windows (read-only, for security) using
ext2fsd.  That makes it easy to run Octave in Windows directly from the Linux
drive:
As soon as mxe-octave emits "generating installer" I quit the build process
(Ctrl-C); at that moment the complete installation as it would be on Windows
is present in the mxe-octave/dist/octave-<date> subdir. One can directly run
octave.vbs from there (no OF packages as octave-packages can't be generated on
a read-only drive but that's a minor issue here).
That'll save (at least in my case) ~20 mins waiting time for the
nsis-installer generating phase, + some minutes to copy the installer over,
and 5-10 mins. to install or unzip Octave in Windows.  Rebooting with an SSD
drive takes < 1 minute.  
I suppose a similar setup (w/o need for reboot) can be gotten by connecting
one's /home drive to Windows-in-a-virtual-PC.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?44338>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/