Re: GSoC project about binary packaging

[PhilipNienhuis]

Michael Goffioul 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:
> :
> <snip>
> - 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

Or we could have the user rely on "pkg install -forge ....".
Only some basic development tools are needed for that with (at least for
MinGW) modest disk space requirements.
The extremes are all OF packages pre-built (and individually selectable),
and none but then including build tools. Your suggestion above is somewhere
in between. I wonder which option would require the lowest maintenance
burden.
Skipping the preparation (and required maintenance) of an arbitrary set of
OF core packages will save precious time for the GSOC student, its mentors
and (later on) maintainers.

I don't know what the best option would be.


> :
> <snip>
> - 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

Is that really true? (I honestly don't know)

My suggestion to merge new MinGW installations into existing ones is based
on the fact that the MinGW directory tree closely mimics the one in Linux
systems. Which leads me to suspect that an in-situ upgrade should be
possible just like on Linux. 

The most relevant stumbling block is how to handle the dependencies (.dll
files) in /bin. But as long as those are compatible it might just work to
either leave them alone, or upgrade them as well. Or maybe they can be put
in some /bin/i686-pc-mingw32-api-v<version>+ subdir and added to
octave-version-specific PATHs (wild guess).

I suggested this because for every Octave invocation on my system(s) I have
to copy over all my preferences (octaverc, paths to some binaries, fig2dev
and pstoedit, favorite editor, etc). It would be nice if octaverc could be
stored somewhere in my Windows user profile (is that possible?) and
automatically be picked up by new Octave installations.


> :
> <snip>
> 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?

Given the available bits and pieces I suppose creating the binary MinGW
(MSVC) installer itself shouldn't take much time anyway.
OTOH fixing the rough edges in mxe-octave may need more time.

After I posted that 64-bit suggestion, I was reading up on various MinGW
sites and I got the impression that 64-bit MinGW maybe isn't so mature yet.
There are some parallel MinGW-based projects that claim better 64-bit
support.  Or am I mistaken?
(Does MSVC allow 64-bit builds?)

Do we have a clear view of the pros and cons of 64-bit Octave? Can it be
mixed with 32-bit packages? Would it have a smooth binary interface to
32-bit SW?
Since a few months I work with a mix of 32-bit and 64-bit Windows systems
(at home and at work) and every week I find smaller or bigger
incompatibilities with 64 & 32-bit SW. One of those is that the OF windows
package (32 bit) won't work with 64-bit MS-Office.

Nevertheless I think at some point we'll have to make a start with 64-bit
Octave on Windows anyway. If this project can give us a headstart I'm all in
favor, even if 64-bit doesn't get completely finished. I do think the
primary aim is to get a reliable, easily maintainable 32-bit binary
installer for a feature complete Octave.


> <rest snipped>

Philip



--
View this message in context: 
http://octave.1599824.n4.nabble.com/GSoC-project-about-binary-packaging-tp4654636p4654709.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.