Message: 8
Date: Sun, 3 Nov 2013 13:19:44 -0800 (PST)
From: PhilipNienhuis<address@hidden>
To:address@hidden
Subject: Re: MXE-Octave & release candidates
Message-ID:<address@hidden>
Content-Type: text/plain; charset=us-ascii
Rik-4 wrote
>On 11/03/2013 10:00 AM,
>octave-maintainers-request@
> wrote:
>>Message: 2
>>Date: Sun, 3 Nov 2013 08:02:15 -0800 (PST)
>>From: PhilipNienhuis <
>pr.nienhuis@
>>
>>To:
>octave-maintainers@
>>Subject: Re: 'make distcheck' passing
>>Message-ID: <
>address@hidden
>>
>>Content-Type: text/plain; charset=us-ascii
>>
>>Rik-4 wrote
>>> >11/2/13
>>> >
>>> >At least on a Linux system the build system can successfully
create
>>> >release
>>> >candidates. There is still a problem with some of the images
in the
>>> >manual
>>> >that have legends. But, I think it would not hurt to start
trying to
>>> >build
>>> >a release candidate through MXE-Octave; This is bound to
expose more
>>> >issues.
>>What do you mean exactly with "release candidate"? A binary
distribution
>>that can be installed on Windows?
>I simply want us to get started on this process early because it
involves
>two additional steps to get right 1) MXE-Octave build needs to work, 2)
>Windows Installer needs to package MXE-Octave.
I'm not sure I can follow here.
The MXE-octave build does work, although (Windows) not natively (that is,
not completely) and the cross-version has issues with llvm (and possibly
OpenBlas on my box). I can't vouch for Mac OSX builds from mxe-octave but
from what I've read it needs attention too.
The Windows installer's only purpose is to package a compiled Octave
and all
built dependencies (runtime libs) + some support SW (awk, makeinfo, sed,
gcc, etc), in order to be able to install & run Octave on Windows. No
more
no less.
Given the fact that Windows offers a fairly homogeneous runtime
environment
to SW (with some exceptions as regards Win 8), much unlike the more
fragmented Linux and *nix world where every distro has its unique
combo of
SW and SW versions, I think there's no need for rigorous testing at
the make
distcheck level for Windows builds. Rigorous testing of the binary's
correctness and performance should do.
On Windows Octave runs fairly self-contained and somewhat isolated
from the
rest of the system, MinGW versions probably more than MSVC versions. From
what I've seen at work I think user priviliges (or rather lack thereof)
could pose more of a problem at execution time given the large number of
individual small .exe files in /bin.
>Each step could have
>problems that might cause delay. For example, I know that gnuplot-4.6.1
>was being used in one of the MXE builds and this needs to be updated
to at
>least 4.6.2 to solve a problem reported on Savannah. Second, we should
>avoid gcc-4.8.2 in the MXE build.
On yesterday's MXE build (with latest updates for mxe-octave & Octave):
>>system ("gnuplot --version")
gnuplot 4.6 patchlevel 1
ans = 0
so that needs updating;
>>system ("gcc --version")
gcc (GCC) 4.8.1
==> at least you don't need to worry about gcc:-)
Philip