Exactly. I see no reason why is has to be installer OR zip. Most open source projects provide *both* and leave it up to the downloaders.
(Also, I don’t believe Roman was ever advocating for *not* providing a zip.)
How does creating the installer work? Is it be a script that just bundles the build/zip file contents etc? If so, I see no reason why calling a script can’t be added to the current Windows build process that already generates a zip …
-------- Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Nov 10, 2015, at 11:53 AM, pd-dev-request@lists.iem.at wrote:
From: Hans-Christoph Steiner <hans@at.or.at mailto:hans@at.or.at> Date: November 10, 2015 at 8:03:59 AM MST To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at Subject: Re: [PD-dev] Windows installer for Pd
IOhannes m zmoelnig:
On 2015-11-10 11:29, Roman Haefeli wrote:
I tried to do all the work and would welcome some feedback.
i think it's one of the beautiful sides of Pd that you do *not* need an installer (even on windows!) and can run it from any media you like (even if it's a read-only CD).
probably the best thing would be to have a menu-entry (maybe hidden in the "preferences"), where people could enable things like file-association and startup menus with the click of a button).
A .zip for Windows is very useful. But that is a separate question. Windows users expect installers. And making an installer does not prevent also a .zip file from being made and used. Pd-extended has both for Windows.
.hc
On Tue, 2015-11-10 at 12:13 -0700, Dan Wilcox wrote:
Exactly. I see no reason why is has to be installer OR zip. Most open source projects provide *both* and leave it up to the downloaders.
(Also, I don’t believe Roman was ever advocating for *not* providing a zip.)
How does creating the installer work?
I tried it with NSIS (Nullsoft Scriptable Install System). You write a .nsi script and then you compile the script with NSIS compiler. The result is an installer as exe.
The not so nice part about NSIS is that you have to list every single file of your source packet explicitly and tell it where to install. Since it is inconvenient to touch that script whenever a new version is released, I added a bash script that creates the file list automatically for a given Pd-for-Windows folder.
Once you have Wine and NSIS installed, it's really only a matter of running the included bash script to create an updated Pd installer. I only tried it on Linux, but if you have bash on Windows, it should work there as well.
You can try it yourself: http://www.netpd.org/~roman/tmp/nsis_installer/
Roman
Is it be a script that just bundles the build/zip file contents etc? If so, I see no reason why calling a script can’t be added to the current Windows build process that already generates a zip …
I'll have a look at this and if it works for me I'll be happy to use it to make an installer for the 0.47 release (late Dec. probably :)
M
On Tue, Nov 10, 2015 at 09:54:34PM +0100, Roman Haefeli wrote:
On Tue, 2015-11-10 at 12:13 -0700, Dan Wilcox wrote:
Exactly. I see no reason why is has to be installer OR zip. Most open source projects provide *both* and leave it up to the downloaders.
(Also, I don’t believe Roman was ever advocating for *not* providing a zip.)
How does creating the installer work?
I tried it with NSIS (Nullsoft Scriptable Install System). You write a .nsi script and then you compile the script with NSIS compiler. The result is an installer as exe.
The not so nice part about NSIS is that you have to list every single file of your source packet explicitly and tell it where to install. Since it is inconvenient to touch that script whenever a new version is released, I added a bash script that creates the file list automatically for a given Pd-for-Windows folder.
Once you have Wine and NSIS installed, it's really only a matter of running the included bash script to create an updated Pd installer. I only tried it on Linux, but if you have bash on Windows, it should work there as well.
You can try it yourself: http://www.netpd.org/~roman/tmp/nsis_installer/
Roman
Is it be a script that just bundles the build/zip file contents etc? If so, I see no reason why calling a script can’t be added to the current Windows build process that already generates a zip …
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
On 2015-11-10 21:54, Roman Haefeli wrote:
The not so nice part about NSIS is that you have to list every single file of your source packet explicitly and tell it where to install. Since it is inconvenient to touch that script whenever a new version is released, I added a bash script that creates the file list automatically for a given Pd-for-Windows folder.
looking at my NSIS installer for Gem [1], it seems that you can use wildcards for adding files. iirc, the main problem with this is, that for the *uninstaller* you need to enumerate the files as well (again you can use wildcards, but then you risk deleting unrelated files)
Once you have Wine and NSIS installed, it's really only a matter of running the included bash script to create an updated Pd installer. I only tried it on Linux, but if you have bash on Windows, it should work there as well.
wine? shouldn't that only be needed to *test* the installer?
anyhow, just a quick warning: i do remember having problems with the linux builds of NSIS: the resulting installers worked great but had the side-effect of "somehow" wrecking the target system in subtle ways. (IIRC after running the installer, people stopped being able to use M$ outlook and weird things like that; while i never found out the actual cause of the problem, i was able to confirm that problems started when using the installer built on my Debian system and that they did not start when using the installer built on a W32 system (using the same input)).
this was almost 10 years ago: things have hopefully improved since then, but it might be worth doing thorough tests :-)
fgmasdr IOhannes
On Wed, 2015-11-11 at 09:07 +0100, IOhannes m zmoelnig wrote:
On 2015-11-10 21:54, Roman Haefeli wrote:
The not so nice part about NSIS is that you have to list every single file of your source packet explicitly and tell it where to install. Since it is inconvenient to touch that script whenever a new version is released, I added a bash script that creates the file list automatically for a given Pd-for-Windows folder.
looking at my NSIS installer for Gem [1], it seems that you can use wildcards for adding files.
Yes, but when using wildcards the nsi-script still relies on the directory layout not to change. Since we want to actually _move_ the Pd directory as is to its destination (without changing its layout), it seemed more reasonable to me to build the file list on the fly without assuming a directory layout.
iirc, the main problem with this is, that for the *uninstaller* you need to enumerate the files as well (again you can use wildcards, but then you risk deleting unrelated files)
Yes, one more reason to build the list of files dynamically.
Once you have Wine and NSIS installed, it's really only a matter of running the included bash script to create an updated Pd installer. I only tried it on Linux, but if you have bash on Windows, it should work there as well.
wine? shouldn't that only be needed to *test* the installer?
You're right. I could have built makensis (the compiler) on Linux. It seemed easier to me to download their pre-compiled Windows package. If you're going to cross-compile Pd for Windows the Miller way, it's likely you have installed Wine anyway. That is the setup I had in mind.
anyhow, just a quick warning: i do remember having problems with the linux builds of NSIS: the resulting installers worked great but had the side-effect of "somehow" wrecking the target system in subtle ways. (IIRC after running the installer, people stopped being able to use M$ outlook and weird things like that; while i never found out the actual cause of the problem, i was able to confirm that problems started when using the installer built on my Debian system and that they did not start when using the installer built on a W32 system (using the same input)).
Thanks for sharing those experiences! I haven't tried myself to create an installer with a Linux build of makensis and your experiences do not exactly sound encouraging. I tested the resulting installer under Wine, Windows XP (VirtualBox) and Windows 7 (VirtualBox). I didn't run into the problems you described, but of course I wasn't testing much other software after installing. This kind of issues is really hard to test for preemptively.
I tested the following after installing : * Pd runs correctly * Pd files have to correct icon * Pd files are opened with Pd when double-clicked
I tested the following after uninstalling: * The uninstaller can be executed * The uninstaller completely removes Pd from %ProgramFiles% * The uninstaller completely removes the start menu entries * Any entries to the registry added by the installer are removed
If there are more things to be tested on a Windows machine I did not think about, please let me know. To my knowledge, the installer only touches %ProgramFiles%, the start menu, and the registry.
Roman
On 2015-11-11 10:41, Roman Haefeli wrote:
On Wed, 2015-11-11 at 09:07 +0100, IOhannes m zmoelnig wrote:
On 2015-11-10 21:54, Roman Haefeli wrote:
wine? shouldn't that only be needed to *test* the installer?
You're right. I could have built makensis (the compiler) on Linux. It seemed easier to me to download their pre-compiled Windows package.
# apt-get install nsis
If you're going to cross-compile Pd for Windows the Miller way, it's likely you have installed Wine anyway. That is the setup I had in mind.
ah, i see.
Thanks for sharing those experiences! I haven't tried myself to create an installer with a Linux build of makensis and your experiences do not exactly sound encouraging. I tested the resulting installer under Wine, Windows XP (VirtualBox) and Windows 7 (VirtualBox). I didn't run into the problems you described, but of course I wasn't testing much other software after installing. This kind of issues is really hard to test for preemptively.
yes, of course: this was the main reason i ran into it. back then, i did test the installer/uninstaller on a *real* windows host (as opposed to a throw-away virtual machine), and didn't catch any problems: mainly because i wouldn't even think of installing "Outlook" on anything (nor actually *use* the w32 installation)
mfgasdr IOhannes
On Wed, 2015-11-11 at 10:46 +0100, IOhannes m zmoelnig wrote:
On 2015-11-11 10:41, Roman Haefeli wrote:
On Wed, 2015-11-11 at 09:07 +0100, IOhannes m zmoelnig wrote:
On 2015-11-10 21:54, Roman Haefeli wrote:
wine? shouldn't that only be needed to *test* the installer?
You're right. I could have built makensis (the compiler) on Linux. It seemed easier to me to download their pre-compiled Windows package.
# apt-get install nsis
:-)
It didn't even occur to me to check the repos! Thanks!
Roman
Thanks for figuring this out... I've put out an installer on my software page (http://msp.ucsd.edu/software.html) marked "experimental".
If this seems to work I'll be happy to continue including this option.
cheers Miller On Wed, Nov 11, 2015 at 11:05:09AM +0100, Roman Haefeli wrote:
On Wed, 2015-11-11 at 10:46 +0100, IOhannes m zmoelnig wrote:
On 2015-11-11 10:41, Roman Haefeli wrote:
On Wed, 2015-11-11 at 09:07 +0100, IOhannes m zmoelnig wrote:
On 2015-11-10 21:54, Roman Haefeli wrote:
wine? shouldn't that only be needed to *test* the installer?
You're right. I could have built makensis (the compiler) on Linux. It seemed easier to me to download their pre-compiled Windows package.
# apt-get install nsis
:-)
It didn't even occur to me to check the repos! Thanks!
Roman
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
I just tried the installer on a Windows XP machine and it worked fine. Super simple! Thanks Miller for this, and Roman for bringing this up (never tried your installer to be honest...)!
On Mon, Nov 16, 2015 at 2:53 AM, Miller Puckette msp@ucsd.edu wrote:
Thanks for figuring this out... I've put out an installer on my software page (http://msp.ucsd.edu/software.html) marked "experimental".
If this seems to work I'll be happy to continue including this option.
cheers Miller On Wed, Nov 11, 2015 at 11:05:09AM +0100, Roman Haefeli wrote:
On Wed, 2015-11-11 at 10:46 +0100, IOhannes m zmoelnig wrote:
On 2015-11-11 10:41, Roman Haefeli wrote:
On Wed, 2015-11-11 at 09:07 +0100, IOhannes m zmoelnig wrote:
On 2015-11-10 21:54, Roman Haefeli wrote:
wine? shouldn't that only be needed to *test* the installer?
You're right. I could have built makensis (the compiler) on Linux. It seemed easier to me to download their pre-compiled Windows package.
# apt-get install nsis
:-)
It didn't even occur to me to check the repos! Thanks!
Roman
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
great option for windows users! thanks so much!
akntk
On Mon, Nov 16, 2015 at 9:53 AM, Miller Puckette msp@ucsd.edu wrote:
Thanks for figuring this out... I've put out an installer on my software page (http://msp.ucsd.edu/software.html) marked "experimental".
If this seems to work I'll be happy to continue including this option.
cheers Miller On Wed, Nov 11, 2015 at 11:05:09AM +0100, Roman Haefeli wrote:
On Wed, 2015-11-11 at 10:46 +0100, IOhannes m zmoelnig wrote:
On 2015-11-11 10:41, Roman Haefeli wrote:
On Wed, 2015-11-11 at 09:07 +0100, IOhannes m zmoelnig wrote:
On 2015-11-10 21:54, Roman Haefeli wrote:
wine? shouldn't that only be needed to *test* the installer?
You're right. I could have built makensis (the compiler) on Linux. It seemed easier to me to download their pre-compiled Windows package.
# apt-get install nsis
:-)
It didn't even occur to me to check the repos! Thanks!
Roman
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
On 2015-11-11 10:41, Roman Haefeli wrote:
iirc, the main problem with this is, that for the *uninstaller* you need
to enumerate the files as well (again you can use wildcards, but then you risk deleting unrelated files)
Yes, one more reason to build the list of files dynamically.
yes definitely.
btw, nsis allows to "include" additional files, so you could factor-out the file-list snippets from the "static" parts of the installer (license foo,...)
gfmasdr IOhannes
On Wed, 2015-11-11 at 10:48 +0100, IOhannes m zmoelnig wrote:
On 2015-11-11 10:41, Roman Haefeli wrote:
iirc, the main problem with this is, that for the *uninstaller* you need
to enumerate the files as well (again you can use wildcards, but then you risk deleting unrelated files)
Yes, one more reason to build the list of files dynamically.
yes definitely.
btw, nsis allows to "include" additional files, so you could factor-out the file-list snippets from the "static" parts of the installer (license foo,...)
That's what the script does. It generates two nsh files, one for the files to be installed and one for the files to be uninstalled. Those are included in the main pd.nsi.
Roman
On Wed, 2015-11-11 at 09:07 +0100, IOhannes m zmoelnig wrote:
On 2015-11-10 21:54, Roman Haefeli wrote:
The not so nice part about NSIS is that you have to list every single file of your source packet explicitly and tell it where to install. Since it is inconvenient to touch that script whenever a new version is released, I added a bash script that creates the file list automatically for a given Pd-for-Windows folder.
looking at my NSIS installer for Gem [1]
Actually, because of Gem I picked NSIS. I couldn't find the build script for creating the Pd-extended installer and then I found the script for Gem and was happy to have working model.
Roman
-
Alexandros Drymonitis -
Dan Wilcox -
IOhannes m zmoelnig -
Jonghyun Kim -
Miller Puckette -
Roman Haefeli