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