Re: Short report Cygwin Octave-2.9.13

[Benjamin Lindner]

> Dear David
> 
> It is my great honor for your inviting me octave-forge.
> 
> As you pointed out, '--disable-silj-exception' flag on GCC
> is not comtatible standard cygwin install.
> So my current distribution, the GCC configured with this
> flag was basically prepared only for the octave.
> In the octave preparation, 
> 
> export CC='/usr/local/gcc-3.4.4d/bin/gcc'
> export CXX='/usr/local/gcc-3.4.4d/bin/g++'
>    :
>    :
> ./configure .....
> 
> The mkoctfile uses the absolute path to the GCC so that
> the confliction with the standard GCC on the Cygwin is
> avoided.

Won't this lead to troubles if the users moves the package around?
One option you could use ist the possibility to add a postfix to 
the gcc/g++ compilers, and then use this name, or insert the version 
number like 'g++-3.4.4-foo'. Then the distributed compiler would be 
more specfific for the octave release and a mixture of different 
compilers would not mess up.
Another problem that might come up is the fact that the library and 
include paths for the compiler's system files are normally hardcoded
into gcc at build stage. The MingW Package has - I believe - a patch
included, since the binary is relocatable. I'm not so sure if the cygwin
build of gcc also features this.
If you cannot get around this, then the binary build must always
use a fixed installation path.

> I found the following post from search engine, so I tried
> gcc-3.4.4-3.
> http://sourceware.org/ml/cygwin/2004-11/msg00007.html
> 
> As for the standalone package, do you mean the package
> like the octave-forge 2.1.73 ?
> 
> In my opinion, it is questionable to distribute the
> standalone packge like the the octave-forge 2.1.73.
> The MSVC octave-2.9.13 is now officially distributed, I
> think that most windows users use it.

And hopefully also the (upcoming) mingw-builds :)
 
> The purpose of my binary distrubuion of the cygwin octave
> is for daily users of cygwin like me.
> (I currently uses the octave and the cygwin gnuplot. )
> 
> Consulting the history of octave-forge windows
> distribution, I found the following 
> 
> octave-2.1.42-cygwin (2003-03-03 21:00) 
>   octave-2.1.42-gnuplot-octaveforge-...
>      :
>      :
> 
> I think that this type of distribution will be reasonable.
> 
> However, to avoid confusion, the binary should not be
> installed in /usr/bin or /usr/local/bin.
> I think that it will be installed like
> /usr/bin/octave-2.9.13.

For the sake of throwing in another opinion: Since the installation 
path will probably have to be fixed (see above) I would choose something
more distinct like /opt/octave[/-]2.9.13 or something like that, to
make clear that the binary does not fit into the 
standard-cygwin-installation-folder-structure.

> In the directry, all packages, octave, gnuplot4.3, GCC,
> the related library, octave-forge functions.

Good idea - this way the octave package will be (more) independent of the 
cygwin setup environment.

> My idea is:
> 
> 1. Basic Packege : octave and gnuplot4.3
> 2. Octave-forge binary package and its octave script
> installer.
> 3. Developer kit : GCC and the related libraries and
> included files.
> 
> Thank you again and it will be grateful for me if you will
> give me the reply.
> 
> I am also waiting for other contributors opinion.

I would not separate into basic and developer. To me this is one unit
that belongs together. I know that the current cygwin octave packages
split into a number of sub-packages but this is not the way I would
choose.
Having the forge 'toolboxes' seperately I agree, since it resembles 
a kind of 'add-on' functionality - like a toolbox.
OTOH, seperating the developer stuff would enable to update the octave
release without re-packing the (same) gcc environment, and would also 
yield smaller binaries. 

benjamin

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer