octave-maintainers
[Top][All Lists]
Advanced

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

Re: GSoC project


From: Michael Goffioul
Subject: Re: GSoC project
Date: Mon, 17 Jun 2013 19:20:32 -0400

On Mon, Jun 17, 2013 at 5:36 PM, Philip Nienhuis <address@hidden> wrote:
 >> 2) implement a user-friendly installer for Windows; here my
suggestion is
 >>> to re-use (and re-engineer) the installer I used to use for my MSVC
 >>> binaries
 >>>
 >>
 >> Can you give me some resources of the installer you had used earlier?

In MXE there's already a basic installer (NSIS) built in (see #8051 in the
patch tracker). In Octave-Forge there's an older NSIS build script for the
3.2.4 Octave binary, see:
http://sourceforge.net/p/octave/code/HEAD/tree/trunk/octave-forge/admin/Windows/mingw32/octave.nsi.in

That's funny. The reference above is actually a rip-off my own installer
script... :)

Did Benjamin rework yours? (I assume the URL points to the script he used; that is, Jordi pointed me to it some years back when I mentioned Benjamin's installer to someone)
Wouldn't surprise me, your work is all over the place.

Yes, Benjamin initially re-used a large part of my stuff: patches and build scripts.
 
 > OK it takes up a bit of disk space [1] (should be no big deal these days)
 > but it is very convenient for the majority of potential Windows users to
 > have this build environment already present in their Octave installation.
 > For the developers there's an advantage too: user support, debugging and
 > solving problems gets a lot easier if the included build tools are
 > standardized.
 >
 > [1] Today's cross-compiled MXE binary takes up around 500 MB after
 > installation in Windows. This includes a build environment sufficiently
 > complete for binary octave-forge packages (provided these do not need
 > additional dependencies).

Well, if all developers are using the same reasoning, your HDD will
quickly get cluttered :). The fact that disk space is cheap these days
is not a reason to waste it.

200 MB for MSYS/MinGW is still better than 2.2 GB for MSVC. At least it would allow for installing binary packages without (hopefully) provoking too much user support requests ("How can I get package 'foo' installed?")

I didn't say MSVC was better in that regard. It's installed size is indecent. But in fairness, though there are lots or crap, a full installation of MSVC provides much more than a bare MSYS/MinGW.

Note that you could also apply the "cheap" HDD reasoning to CPU, and not bother about the performances of your software because today's CPU are powerful enough. Well, if everyone is doing the same, you get a crawling computer. I just don't like these kinds of reasoning.
 
 As a user, if I already have MSYS installed
on my system, I'd rather have octave use it instead of installing its
own version. Octave should still be shipped with a stripped down version
of MSYS, but its installation should be optional.

Well, you are not quite a standard 'plain-vanilla' Windows user.

I suppose for the majority of Windows users-as-we-think-we-know-them it does make sense to include some basic standardized build tools to enable them to install/upgrade binary packages directly from Sourceforge, or from anywhere else for that matter.
AFAICS the included build tools in mxe-octave suffice for just that. I tried doing more (i.e., building Octave) but to do so I needed to expand and augment it considerably to just get a first start (configure to run).

A main motive of the mxe build (as I understood it from jwe) was to offer a standardized environment so that support and assistance with debugging etc. would be simplified for the developers.
It would also save developers the hassle of separately packaging OF packages, like you did for the MSVC binaries (although I know that e.g., several Linux distros have other opinions, or traditions).

Perhaps the build tools/MSYS could be an installation time choice that should explicitly be deselected to avoid installing them.

Note that I didn't say it shouldn't be bundled. I just said its installation should be optional and it should be able to work with an existing MSYS installation. The installer I wrote has some internal mechanism to auto-detect MSYS, but it's probably outdated as MSYS has changed internally. It's not a big issue anyway, but I find irritating that every single software installs its own version of some libraries. I cannot count the number of duplicated DLL I have on my system after installing software like python, MiKTeX, GTK+/Gimp, Qt...

Last time I installed git for windows, it also installed its own MSYS installation. Why the hell can't it use my existing MSYS?

Michael.


reply via email to

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