Re: hosting mingw binaries for octave

[David Bateman]

Benjamin Lindner wrote:
>>> Good point. 
>>> How can I get access to the octave-forge project?
>>>   
>>>       
>> Asking here is a good start.. We need your sourceforge username though
>> as I don't believe you are registered as an octave-forge developer..
>>     
>
> Here you go: SF username is lindnerb
>   
Ok, added and you are marked as a release technician.. However, I'd
suggest at least one test release prior to an upload to sourceforge..

>   
>> You'd also need to be marked as a release technician in octave-forge to
>> be able to upload files. However, we'd need to think about how to
>> reorganize the release page to handle up to three different and
>> concurrent Windows releases (MSVC, cygwin and MinGW)...
>>     
>
> Anytime. I just took a look at the download page on sf and recognized 
> that I am a bit lagging behind in being up-to-date. Wow, there are 
> quite a number of releases available. I definitely need to catch up...
> Now I see the argument of having the binaries all togther at one site.
>
> We should probably think of reorganizing, true. 
> At first I was a bit confused because the mac binaries are clearly
> distinguishable, but it is not clear whether a windows binary is
> native or cygwin. If we add a mingw-binary also, there should be some
> distinction visible. Then an octave binary is packaged as 
> "Octave Forge Windows". shouldn't it be more like "octave windows"
> and the forge packages under "octave forge Windows".
> But I'm slicing hair probably.
>   
The assumption is that there is a single Windows release, upto and
including 2.1.73 it was based on cygwin and after that it was based on
MSVC.. There was some argument that we shouldn't host a cygwin
installer, but rather get any cygwin port included upstream in cygwin
itself, as cygwin has its own distribution method. So perhaps we should
ignore cygwin. Additional constraint is that because the MSVC binary
can't include a compiler for legal reasons, all of the octave-forge
packages are compiled for the MSVC. However, to avoid the binary size
being too big, many of these are available as separate add-on packages
that can be downloaded at install time.

There are then two basic questions to address. Firstly the file
hierarchy and second the file naming schemes to separate the MSVC from
the MinGW releases. For the first point the sourceforge file release
system limits severely the hierarchy to be something like

Package
  -> Release
  -> -> File

There can be multiple packages, and each package can have multiple
releases. Each release can contain multiple files, but these are the
files to download and so must have the name of the file itself.

At the moment the is one package for the MSVC installer and another for
the add-on packages. We might continue this and just add an additional
package in the file hierarchy for the MinGW binaries, or we might have
one package and different releases. As the releases are sorted
chronologically it probably makes sense to have a separate package for
MinGW. Assuming you want the add-on package structure of the MSVC
binaries, the hierarchy might be

Octave Forge Windows MinGW
   Octave 2.9.13 for Windows MinGW installer
       octave-2.9.13-mingw-setup.exe
Octave Forge Windows MinGW - Additional Packages
    Octave 2.9.13  MinGW - Additional Packages
        octave-2.9.13-mingw-bim-0.0.1-setup.exe
        ....
Octave Forge Windows MSVC
   Octave 2.9.13 for Windows MSVC installer
       octave-2.9.13-msvc-setup.exe
Octave Forge Windows MSVC - Additional Packages
    Octave 2.9.13  MSVC - Additional Packages
        octave-2.9.13-msvc-bim-0.0.1-setup.exe
        ...

Note that all of the file names will be required to identify whether
they are for MSVC or MinGW. The differences between the two releases
might be explained in the notes for the packages and releases..

>  
> I had a look at Michaels files in the forge cvs.
> I took a bit a different approach in bundling the 
> download/applypatch/configure/make/install process for the
> dependencies and octave itself. 
> We can discuss on how to merge into one uniform build-enviroment for 
> msvc and mingw. But I would put this one grade less priority than 
> the binaries itself. 
>   
Getting whatever build process you use into a script and committed to
CVS is basic in making the release supportable in the future... So I'm
not sure this is that secondary..

Regards
David

-- 
David Bateman                                address@hidden
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary