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

[Andy A. <ad...@si...>]

On Sat, 1 Mar 2003, Paul Kienzle wrote:
> Andy Adler wrote:
> >On Fri, 28 Feb 2003, Paul Kienzle wrote:
> >>Andy Adler wrote:
> >>>I'd like to upload my octave-for-windows to octave-forge.
> >>>I've not had a bug report for a few weeks now.
> >>>
> >>>Could you create a "octave for windows" package
> >>>category and I'll add the file there.
> >>>
> >>Don't we already have one in the form of octave-forge-cygwin?  Or is
> >>this a pure octave package?
> >>
> >This would be for self contained octave-for-windows, using
> >the nsis installer.
> >
> >I consider this to be distinct from octave-forge-cygwin,
> >which I intend to keep up, as well.
> >
> The difference is that octave-forge-cygwin is a developer
> tarball which installs into an existing cygwin installation and
> the other is a stand-alone which does not require cygwin?
>
> Ideally, I would like the developer version to be tied
> to the standalone version so that oct-files created
> with the developer version can be installed in the
> standalone version and just work.

There are two questions here:

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.

> 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.


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.
      - 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.

   - 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.

> 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 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.

Andy