octave-dev

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

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

Andy Adler wrote:

>On Fri, 28 Feb 2003, Paul Kienzle wrote:
>
>>Andy Adler wrote:
>>
>>>Paul,
>>>
>>>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.

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

I realize I've said all this before and we are not there yet.

Some issues that remain to be worked out:

* do we ship multiple dll's or one big exe which we
link octfiles against?

* do we build with a light kernel or do we build all
the DLD-FUNCTIONS as builtins?

* if heavy kernel, do we build octave-forge as oct-files
or do we make a super heavy kernel which includes them
all?

* can we build lapack-plain.dll and various lapack-atlas
dlls so that atlas enabling is just a matter of copying the
proper dll to lapack.dll?

* do we build libstdc++.dll?  Or do we dump the
contents of libstdc++.a into libcruft or (in the heavy
kernel world) into the octave.exe?

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.

The heavy kernel option will need some work to make
sure it can support the separately compiled option.  

If super heavy is the preferred option, we could
rework the octave-forge cc files so that they use the
DLD-FUNCTIONS style of #include "blah.h" rather
than #include <octave/blah.h>.  That way you don't
have to construct the octave include directory as part
of the octave source tree. Then it is only a matter of
changing octave/src Makefile so that it automatically
builds everything in the DLD-FUNCTIONS directory
which means that we don't have to edit anything by
hand when building a new release version.

Comments?

Paul Kienzle
pki...@us...

[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

[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?