Windows installer

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Windows installer

John W. Eaton
Administrator
John and Michael,

The latest Windows installer looks good.  Thanks for all the work you've
been doing on this project.  Do you think it is ready to release?  Or do
you think we should wait until we can include compiled Octave Forge
packages in the installer?  I don't think that's necessary, though I'm
sure people will complain about it since previous installers did include
them, plus other things like a selection of accelerated BLAS options.

Should we make the GUI the default on Windows?  I expect that's what
most Windows users will want.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: Windows installer

Markus
Am 2014-01-06 13:43, schrieb John W. Eaton:

> John and Michael,
>
> The latest Windows installer looks good.  Thanks for all the work
> you've been doing on this project.  Do you think it is ready to
> release?  Or do you think we should wait until we can include compiled
> Octave Forge packages in the installer?  I don't think that's
> necessary, though I'm sure people will complain about it since
> previous installers did include them, plus other things like a
> selection of accelerated BLAS options.
>

For me it's more "lightweight" without packages. Furthermore >> pkg
install -forge -auto PKGNAME is not very difficult.

> Should we make the GUI the default on Windows?  I expect that's what
> most Windows users will want.

I would prefer this for Windows too.

>
> jwe

--
https://github.com/markuman
Jabber: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Windows installer

Richard Crozier
On 06/01/2014 13:16, Markus wrote:
> For me it's more "lightweight" without packages. Furthermore >> pkg
> install -forge -auto PKGNAME is not very difficult.


Does that actually work on Windows for packages which must be compiled?

Richard

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Reply | Threaded
Open this post in threaded view
|

Re: Windows installer

John W. Eaton
Administrator
On 01/06/2014 08:35 AM, Richard Crozier wrote:
> On 06/01/2014 13:16, Markus wrote:
>> For me it's more "lightweight" without packages. Furthermore >> pkg
>> install -forge -auto PKGNAME is not very difficult.
>
>
> Does that actually work on Windows for packages which must be compiled?

It should, because the Octave installer includes GCC and other build tools.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Windows installer

Markus
In reply to this post by Richard Crozier
Am 2014-01-06 14:35, schrieb Richard Crozier:
> On 06/01/2014 13:16, Markus wrote:
>> For me it's more "lightweight" without packages. Furthermore >> pkg
>> install -forge -auto PKGNAME is not very difficult.
>
>
> Does that actually work on Windows for packages which must be compiled?
>

The last time I've tried that, it works. If it wouldn't work, I wouldn't
release a binary for Windows.

> Richard

--
https://github.com/markuman
Jabber: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Windows installer

Jordi Gutiérrez Hermoso-2
In reply to this post by John W. Eaton
On Mon, 2014-01-06 at 08:46 -0500, John W. Eaton wrote:

> On 01/06/2014 08:35 AM, Richard Crozier wrote:
> > On 06/01/2014 13:16, Markus wrote:
> >> For me it's more "lightweight" without packages. Furthermore >> pkg
> >> install -forge -auto PKGNAME is not very difficult.
> >
> >
> > Does that actually work on Windows for packages which must be compiled?
>
> It should, because the Octave installer includes GCC and other build
> tools.

It won't work seamlessly for some of the more esoteric packages that
have external dependencies, like instrument control or GSL. Probably
not a huge concern, though.

- Jordi G. H.


Reply | Threaded
Open this post in threaded view
|

Re: Windows installer

PhilipNienhuis
In reply to this post by Richard Crozier
Richard Crozier wrote
On 06/01/2014 13:16, Markus wrote:
> For me it's more "lightweight" without packages. Furthermore >> pkg
> install -forge -auto PKGNAME is not very difficult.
Sure, until a user lands her-/himself in the dependency maze, e.g. with signal and statistics packages. Not hard for us, but maybe a stumbling block for novices.

But I think it is a good thing to have (at least) a bare-bones Windows installer up on e.g., Octave-Forge, and later on a more complete one elsewhere.

Does that actually work on Windows for packages which must be compiled?
Yes it does for the MinGW installer version, as that has all build tools included.

The MSVC installer requires another 2.2 GB disk space of mostly crap for the Visual C++ Express build tools (as the VCExpress installer installs all or nothing), + some paths setup stuff. Works fine though, once set up.

Philip
Reply | Threaded
Open this post in threaded view
|

Re: Windows installer

c.-2
In reply to this post by Markus

On 6 Jan 2014, at 14:16, Markus <[hidden email]> wrote:

> urthermore >> pkg install -forge -auto PKGNAME is not very difficult.
we shouldn't be recomending the use of the '-auto' option, actually I thought
it was going to be deprecated ...

c.
Reply | Threaded
Open this post in threaded view
|

RE: Windows installer

JohnD
In reply to this post by John W. Eaton


-----Original Message-----
From: John W. Eaton [mailto:[hidden email]]
Sent: Monday, January 06, 2014 7:43 AM
To: John Donoghue; Michael Goffioul
Cc: octave maintainers mailing list
Subject: Windows installer

John and Michael,

The latest Windows installer looks good.  Thanks for all the work you've
been doing on this project.  Do you think it is ready to release?  Or do you
think we should wait until we can include compiled Octave Forge packages in
the installer?  I don't think that's necessary, though I'm sure people will
complain about it since previous installers did include them, plus other
things like a selection of accelerated BLAS options.

Should we make the GUI the default on Windows?  I expect that's what most
Windows users will want.

Jwe


----

I have shortcuts created for both GUI and command line.
Since both are there, perhaps instead on making one 'default' should we make
it clearer of command line vs GUI mode on the shortcuts.

Rather than automatically starting the GUI after install (and having to
decide what to make 'default') remove the run octave option from the GUI (I
dont know about everyone else, but I always uncheck the run program option
whenever installing something new) Anyone else?

I thought about the compiled packages for a while and I think it is going to
be hard to do on a cross build system - the easier way to do this will be
create the compiled packages on a native machine and then include them as
binaries in the cross build system. Otherwise either tell the user there are
packages in the source directory, or provide the option in the installer to
compile the packages at the end of the install ?


Reply | Threaded
Open this post in threaded view
|

Re: Windows installer

Thorsten Liebig
In reply to this post by John W. Eaton
Am 06.01.2014 13:43, schrieb John W. Eaton:

> John and Michael,
>
> The latest Windows installer looks good.  Thanks for all the work you've been doing on this project.  Do you think it is ready to release?  Or do
> you think we should wait until we can include compiled Octave Forge packages in the installer?  I don't think that's necessary, though I'm sure
> people will complain about it since previous installers did include them, plus other things like a selection of accelerated BLAS options.
>
> Should we make the GUI the default on Windows?  I expect that's what most Windows users will want.
>
> jwe
>

I would recommend to upload the zip-version (additionally to the installer version) as well to octave.org
It could be named something like "portable Octave version".
The advantage is that you don't need admin privileges to install Octave, but you can even put it on some USB or NAS device etc.
The obvious disadvantage are the missing menu and desktop short cuts. But that should be clear to anybody looking for a portable version?

regards
Thorsten
Reply | Threaded
Open this post in threaded view
|

Re: Windows installer

John W. Eaton
Administrator
In reply to this post by JohnD
On 01/06/2014 09:45 AM, John D wrote:

> I thought about the compiled packages for a while and I think it is going to
> be hard to do on a cross build system - the easier way to do this will be
> create the compiled packages on a native machine and then include them as
> binaries in the cross build system.

I agree that it is not easy now, but longer term I'd like to be able to
cross compile the packages.

jwe


Reply | Threaded
Open this post in threaded view
|

RE: Windows installer

JohnD


-----Original Message-----
From: John W. Eaton [mailto:[hidden email]]
Sent: Monday, January 06, 2014 10:02 AM
To: John D
Cc: 'octave maintainers mailing list'
Subject: Re: Windows installer

On 01/06/2014 09:45 AM, John D wrote:

> I thought about the compiled packages for a while and I think it is
> going to be hard to do on a cross build system - the easier way to do
> this will be create the compiled packages on a native machine and then
> include them as binaries in the cross build system.

I agree that it is not easy now, but longer term I'd like to be able to
cross compile the packages.

jwe

---

How about for now changing the run octave checkbox on the installer to
"Install provided packages" and at the end of the install, have it run the
build_packages.m script ?

Reply | Threaded
Open this post in threaded view
|

RE: Windows installer

Philip Nienhuis
John Donoghue-2 wrote
-----Original Message-----
From: John W. Eaton [mailto:[hidden email]]
Sent: Monday, January 06, 2014 10:02 AM
To: John D
Cc: 'octave maintainers mailing list'
Subject: Re: Windows installer

On 01/06/2014 09:45 AM, John D wrote:

> I thought about the compiled packages for a while and I think it is
> going to be hard to do on a cross build system - the easier way to do
> this will be create the compiled packages on a native machine and then
> include them as binaries in the cross build system.

I agree that it is not easy now, but longer term I'd like to be able to
cross compile the packages.

jwe

---

How about for now changing the run octave checkbox on the installer to
"Install provided packages" and at the end of the install, have it run the
build_packages.m script ?
That check box had better be called "Build provided packages (may take some time!)"
(it takes ~10 minutes to build the original 10 or so packages included in the first mxe builds on my 2.5 Ghz Core DUo WinXP box).


While we're here, the build_packages script may require some changes:

1. Many developers here think that packages shouldn't be loaded by default. So should the "-auto" flags be changed into "-noauto"?

2. At the end of build_packages some message is needed to inform users that packages must be loaded (+ how to do that) before they can be used.

3. The "-global" flag makes no difference, that is, not on my 3 Windows boxes; it can be dropped I think unless it works or is required on Mac OSX.
Besides, the Windows installer makes shortcuts (Start Menu, desktop) for the current user only.

4. The build-packages script sometimes fails (for packages that I added manually).
Perhaps a try-catch around each pkg install command, or around pkg install commands for sets of interdependent packages, could be handy.


As to 3., I think we also need a radio button for installation for current user or all users (Admin priviliges required for the latter). Inside the make_installscript.sh at some place the NSIS command "setShellVarContext" should be set accordingly (http://nsis.sourceforge.net/Reference/SetShellVarContext), plus maybe (as per http://nsis.sourceforge.net/Shortcuts_removal_fails_on_Windows_Vista)
RequestExecutionLevel user
RequestExecutionLevel admin

Philip
Reply | Threaded
Open this post in threaded view
|

Re: Windows installer

John W. Eaton
Administrator
On 01/10/2014 07:31 AM, Philip Nienhuis wrote:

> While we're here, the build_packages script may require some changes:
>
> 1. Many developers here think that packages shouldn't be loaded by default.
> So should the "-auto" flags be changed into "-noauto"?

I added -auto because I was trying to deliver something that would
have those packages loaded by default.  That's what my customer was
expecting.

> 3. The "-global" flag makes no difference, that is, not on my 3 Windows
> boxes; it can be dropped I think unless it works or is required on Mac OSX.
> Besides, the Windows installer makes shortcuts (Start Menu, desktop) for the
> current user only.

Doesn't -global put the packages and the package list in a directory
under $OCTAVE_HOME instead of the user's $HOME?  If compiled packages
are included in the installer, then I think this is what we need.
Also, I recall that the package list file uses absolute path names, so
those need to be patched up by the installer to match the actual
location of the installed files.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: Windows installer

Philip Nienhuis
John W. Eaton wrote
On 01/10/2014 07:31 AM, Philip Nienhuis wrote:

> While we're here, the build_packages script may require some changes:
>
> 1. Many developers here think that packages shouldn't be loaded by default.
> So should the "-auto" flags be changed into "-noauto"?

I added -auto because I was trying to deliver something that would
have those packages loaded by default.  That's what my customer was
expecting.
OK, so we're overruled :-)

> 3. The "-global" flag makes no difference, that is, not on my 3 Windows
> boxes; it can be dropped I think unless it works or is required on Mac OSX.
> Besides, the Windows installer makes shortcuts (Start Menu, desktop) for the
> current user only.

Doesn't -global put the packages and the package list in a directory
under $OCTAVE_HOME instead of the user's $HOME?  If compiled packages
are included in the installer, then I think this is what we need.
Also, I recall that the package list file uses absolute path names, so
those need to be patched up by the installer to match the actual
location of the installed files.
Ah, I now realize that "-global" is simply the default; it does put OF packages in the <OCTAVE_HOME>/[share|lib]/octave/package hierarchy.
"-local" tries to put it in the "HOME" dir (actually %USERPROFILE%\octave), indeed.

On Windows I'd prefer to have OF packages in the OCTAVE_HOME hierarchy. I use several Octave versions next to each other and they aren't fully compatible, not even at m-file level.

Philip