[OctDev] Re: octave for windows on octave-forge

[Paul K. <pki...@us...>]

>
>
>Q1 What we have now:
>
>   I have a heavy version of 2.1.42 (from my website).
>   This exists in both windows installer version (with nsis packager)
>   and as cygwin *tar.bz2 packages.
>
>   I was fixing quite a few bugs originally (I'm up to package version 6)
>   but have not received a bug report for about 3 weeks.
>
>   I propose we put this stuff on octave.sf.net now.
>
>   Sure, its not ideal, but its much better than whats currently on
>   there, and it buys us time to get the next version right.
>
Agreed.

>>In that case, I would like the user and developer
>>versions to be different release files in the same
>>release.  I know sourceforge will support this since
>>I've seen it for example in the tcl file release page:
>>http://sourceforge.net/project/showfiles.php?group_id=10894
>>    
>>
>
>This is not really a user/developer issue. People who like
>cygwin will want octave installed into their cygwin system.
>People who don't care about it will want an *.exe to click on.
>
>I think the different packages should be under different headings.
>"octave-forge-cygwin" means nothing to a windows user.
>They will not think that packages under that heading are for them.
>
>I definitely agree that self-install and cygwin versions should share
>the same build and files.
>
I renamed the category to octave-forge-windows.

Users can find themselves being developers when they
discover an interesting hunk of C code they want to include,
so I think it is best to keep the packages together.  Nobody
starts with octave with the idea that they are going to be
developing oct-files for it, but some fools get sucked
into it and are trapped forever more ;-)

>Q2 What we should have:
>
>   - Best case: A light kernel version with DLD using the
>     dynamic loaded libstd++.dll
>
>     Advantages:
>      - compiles same as UNIX - no need to maintain special build.
>      - each ATLAS in their own DLL - saves space and complexity
>      - reduces newbie questions. One package does everything.
>
>     Disadvantages:
>      - will be big unless we can use libstd++.dll
>      - however, I just tried to build oct-2.1.45 from scratch this
>         way and ran into linking problems.
>
I need more details before I can help, other than
to say "It worked for me..."

>      - another future problem is "dllhell" if a future cygwin release
>         has an incompatible libstd++.dll.
>
>      - I recommend we build octave in /octave or /opt/octave, and
>         then put libstd++.dll in with the other octave dlls.
>         That way our libstd++.dll is private to octave.
>
Agreed.

We could still have a problem because different developers
are using different versions of cygwin with different versions
of stdc++.  Will it be enough to include the C++ headers
and the libstdc++.dll.a in the developer package? 

The developer package is starting to sound big:
    0.3 Mb libcruft.dll.a
    2.3 Mb liboctave.dll.a
    3.0 Mb liboctinterp.dll.a
    1.0 Mb include/octave
    1.5 Mb libstdc++.dll.a
    2.0 Mb include/c++
    ?.? Mb include/lapack
    ?.? Mb include/lapack.dll.a
    0.0 Mb bin/mkoctfile, etc.

I'm assuming the developer package requires the
user package to be installed first, otherwise we
have to add on that.  Fortunately it compresses
well.  The files listed above (sans lapack) compress
to only 0.6 Mb!

I'm not sure the problem is any less if the developer
package is statically linked to libstdc++.

>   - The other options (heavy, semi-heavy, big ...) all have problems.
>     I recommend we try to get the best case working, and not look
>     at the other options until this proves impossible.
>
That's my feeling, unless someone has a good reason
not to use DLLs.  Also, as DLLs, I think it will be
easier to embed octave directly in tcl/perl/R ...

>>I've tested the light kernel option.  It works fine except
>>that the fork problem on recent cygwin for Win 9x is
>>exacerbated (not only is it slow, it also pops up error
>>messages for each loaded oct-file).  The solution is to
>>purge the octave code of fork, but I haven't had a
>>chance to do so yet.
>>    
>>
>
>My opinion on 9x support is not to try very hard. 
>
I have no choice.  Another thing is that removing fork gets us one
step closer to a MinGW version.  With the revised (ugly) signal
handling, Ctrl-C can be made to work, at least in conforming
code.  Foreign code such as lapack will still need trickery.

>I say we put
>up the 2.1.42 heavy option now (which should work fine on 9x) and then
>move to something with dynamic linking in future.
>
Okay.  Shall I leave the -2.1.3x as is, or should I
rename them to -2.1.3x-developer?