octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSoC project about binary packaging


From: Michael Goffioul
Subject: Re: GSoC project about binary packaging
Date: Mon, 24 Jun 2013 07:23:41 -0400

On Mon, Jun 24, 2013 at 3:29 AM, Anirudha Bose <address@hidden> wrote:
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.

You goal for this week is to get octave builds in native and cross MinGW, with all features enabled (LLVM/JIT, OpenBLAS, Java, GUI...). Those builds should pass the test suite (bar the expected failures under MinGW). If there are things not working in MXE, you'll have to fix them along the way. Hopefully, it'll go smoothly and you can then start looking at the installer script before the end of the week.
  
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.

To be honest, I think the size of the packages will not be that big compared to the rest (octave, dependencies, development files, compiler, MSYS...). Anyway, there are 2 trends here:
1) No package in included in the main installer; each package is provided into its own installer, which also contains its own dependencies. I still think it makes sense to provide pre-compiled version of the packages.
2) Include all packages into the main installer.

I'm fine with both options.
 
I think it might be confusing for some users who don't know which BLAS they should install.

The default should be OpenBLAS. The reference BLAS is only there in cases OpenBLAS crashes, as a backup for the user.
 
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?

Octave doesn't really care about BLAS or OpenBLAS, it's just looking for an API. You can compile octave against BLAS and then later on make it run with OpenBLAS, as long as OpenBLAS provides the same API/ABI. So the idea is to compile octave against the reference BLAS. You include both DLL in the installer, let's say libblas.dll and libopenblas.dll. At installation time, depending on the user selection, you install libblas.dll or libopenblas.dll, but whatever choice, the DLL is installed with the name "libblas.dll".

Another possibility would be to install both and have a tool to let the user choose what DLL to use at runtime. For instance installing the 2 DLL: libblasref.dll and libopenblas.dll; then the tool would copy the wanted BLAS as libblas.dll.

Michael.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]