Re: GSoC project about binary packaging

[Anirudha Bose]

Sorry for being out of contact for a few days. I read your detailed proposal and now I will be able to work according to the ideas you have proposed. I am a little behind schedule so I will focus on the first coding session goals, as of now. I will blog about the new goals of this project once I have got a clear idea of the deliverables.

On Mon, Jun 24, 2013 at 1:41 AM, Michael Goffioul <address@hidden> wrote:

Thanks to everybody for all the valuable inputs. Let me try now to make a more detailed plan for this GSoC project. In general, I think the high-level targets for the project should be as follows (pretty close to the original GSoC proposal anyway):

- first code session (until mid-term): MinGW native/cross build with installer generation

- second code session: OS X native build with app bundle

1) MinGW build with installer

This will be based on MXE and allow to make octave binaries using MinGW cross-compiler and native compiler. The build itself should contain as many features as possible. This means:

- OpenBLAS: I would initially go with a 32-bits multi-thread dynamic arch version of the library; because of possible problems on some architectures, I think it makes also sense to ship octave with a reference BLAS; what I used to do in my installers is to ship both, let user select which one to install and install the selected on as the "blas" DLL; in practice it means that octave is compiled against the reference BLAS, but the reference BLAS DLL can get overwritten by the OpenBLAS DLL (using the same name); this works as long as both DLL export the same symbols

- LLVM/JIT

- Java: octave should be compiled with java support; but the JRE should not be compiled or bundled into the installer; the octave/java bridge looks the the JRE at run-time using information from the registry

- GUI: obviously we want the GUI by default compiled into octave

- octave-forge packages: here I'm not sure it makes sense to bundle *all* packages, some of them are "exotic" and not wanted by most users; I would suggest to make a list of must-have core packages, and let the others package be provided as addons with their own installer

 

Instead of including all the octave-forge packages in the installer, can we let the users select the desired packages and download them? If we do include all the packages in the installer itself and let the users choose which ones to install during the installation, the size of the installer will get very large. This is something which is undesirable for someone who wants the basic installation packed in a small setup file.

As mentioned previously, it would be nice to have a smarter installer script able to do more than simply dumping everything into a directory. In particular, the features I have in mind are:

- component selection: things that I think make sense to be (de)selectable: development files (headers, library files, compiler...), GUI, documentation/manuals, octave-forge packages, MSYS (a few elements are still needed by code octave, for the pager and formatting help text)

- if we ship a reference BLAS and OpenBLAS, it's nice to be able to select which one to install

I think it might be confusing for some users who don't know which BLAS they should install. Are you proposing that we build Octave for Windows without OpenBLAS, and just add the DLL file of OpenBLAS if the users wants? In that case what should be the substitute here 

    --with-blas=openblas

in src/octave.mk? Will the --enable-openblas option in configure still be applicable? Is Octave compiled with reference BLAS by default if OpenBLAS is disabled?

- default graphics toolkit selection

- selection of octave forge packages that the user wants autoloaded

- possibility to upgrade an existing installation or install side-by-side; in case of upgrading, I think the only sensible thing to do is to uninstall the previous version and install the new one

- possibility to re-run the installer to install components that weren't install the first time; though I'm not sure how easy this can be done with NSIS, I never looked into that

I will investigate into this and let you know if I find a solution. From what I have read about NSIS, I am not sure how to implement this feature yet.

- possibility to package octave-forge packages into their own installer that is deployed on top an existing installation; the approach I've taken in my installers as to generate a binary archive with "pkg build" then wrap that archive into a NSIS installer

Another thing that Philip has brought on the table, which I find interesting, is to have binaries produced with mingw64. I think having a full 64-bits version of octave would be happily welcome by a number of users. It's an open question, but IMO it can make sense to keep the installer simpler, save time on the implementation, and use that time to be able to produce 64-bits binaries. What do others think?

2) OS X build

Here it's still not clear what's feasible. So, Anirudha, during the first coding session, I'd like you also to think about OS X binary and app bundle generation.

Michael.