I have a list of photos and a photo viewer application (and executable) that I'd like to package as an installer file. What tools can I use to package all the files together, instruct the installer where to copy files to, to automatically run the executable, etc.? An MSI-like installer would be ideal, I think.
There is a list of Install software on Wikipedia. Eliminate those that don't suit your platform/licensing/budget/are discontinued and you should end up with a small list enough to try all of them.
Related
I've cloned it but I didn't find any .exe file, Nor do i see it in programs list in Control Panel of windows. I'am a bit confused as to what cloning means. I know that there is direct download .exe file on vim.org website. Its for sure that I'am beginner for all these. Please help. Thanks for the help in advance.
reading the "installation" section found in the README.md of the vim repo, you can see the filenames containing the instructions that will help you with the installation, depending on your OS.
README_ami.txt Amiga
README_unix.txt Unix
README_dos.txt MS-DOS and MS-Windows
README_mac.txt Macintosh
README_haiku.txt Haiku
README_vms.txt VMS
So, for the full information I suggest you go to those files, or go to the vim website where there is also good information about the installation.
Anyway, I will briefly explain below the information that those files and the vim website say for most common operating systems
If you're on Unix:
git clone https://github.com/vim/vim.git
cd vim/src
make
If you're on Mac
The Macintosh binaries are not on the Vim ftp site. They are produced by a few Macintosh lovers. Often they lag behind a few versions.
MacVim has more a Mac look and feel, is developed actively and most people prefer this version. Most of MacVim was made by Björn Winckler.
MacVim can be downloaded here: link
Or if you prefer, here is the MacVim homepage.
If you're on Windows:
The next instructions were copied from here.
Option A: Using the self-installing .exe
Go to vim.org/download.php and click on self-installing executable (or just click here) and follow the prompts.
Watch out for:
When an existing installation is detected, you are offered to first remove
this. The uninstall program is then started while the install program waits
for it to complete. Sometimes the windows overlap each other, which can be
confusing. Be sure the complete the uninstalling before continuing the
installation. Watch the taskbar for uninstall windows.
When selecting a directory to install Vim, use the same place where other
versions are located. This makes it easier to find your _vimrc file. For
example "C:\Program Files\vim" or "D:\vim". A name ending in "vim" is
preferred.
After selecting the directory where to install Vim, clicking on "Next" will
start the installation.
Option B: Using .zip files
Go to the directory where you want to put the Vim files. Examples:
cd C:\
cd D:\editors
If you already have a "vim" directory, go to the directory in which it is
located. Check the $VIM setting to see where it points to:
set VIM
For example, if you have
C:\vim\vim82
do
cd C:\
Binary and runtime Vim archives are normally unpacked in the same location,
on top of each other.
Unpack the zip archives. This will create a new directory "vim\vim82",
in which all the distributed Vim files are placed. Since the directory
name includes the version number, it is unlikely that you overwrite
existing files.
Examples:
pkunzip -d gvim82.zip
unzip vim82w32.zip
You need to unpack the runtime archive and at least one of the binary
archives. When using more than one binary version, be careful not to
overwrite one version with the other, the names of the executables
"vim.exe" and "gvim.exe" are the same.
After you unpacked the files, you can still move the whole directory tree
to another location. That is where they will stay, the install program
won't move or copy the runtime files.
Change to the new directory:
cd vim\vim82
Run the "install.exe" program. It will ask you a number of questions about
how you would like to have your Vim setup. Among these are:
You can tell it to write a "_vimrc" file with your preferences in the
parent directory.
It can also install an "Edit with Vim" entry in the Windows Explorer
popup menu.
You can have it create batch files, so that you can run Vim from the
console or in a shell. You can select one of the directories in your
$PATH. If you skip this, you can add Vim to the search path manually:
The simplest is to add a line to your autoexec.bat. Examples:
set path=%path%;C:\vim\vim82
set path=%path%;D:\editors\vim\vim82
Create entries for Vim on the desktop and in the Start menu.
That's it!
Vim is open source software, and its source code, i.e. all the technical files that make up Vim is (nowadays) hosted at GitHub.
Cloning that repository means you'll download all of those files to your computer (and with Git as the underlying revision control system, you'll even get the full history of all changes ever done). As Vim supports a very big set of very diverse platforms (Windows, Linux, Mac, ...), the repository itself does not (and should not) contain pre-built binaries, nor a full installer that most users expect to run. So, unless you have the intention to actively contribute to Vim by submitting bug fixes or enhancements, you don't need to clone or do anything with GitHub. If you do want to get technical, src/INSTALLpc.txt contains the instructions for building Vim on Windows. This includes choosing a compiler, installing it and the required dependencies, configuring the build, building, and then finally copying the files to a permanent location on your PC, either manually or by building and then running an installer.
For plain passive consumption of Vim (which is rewarding in itself, but may even lead you to eventually also programming it), the Downloading Vim page on vim.org has all the information that you need, with links to the most popular installers right at the top.
a word on versions
For a casual user, using the latest stable version is recommended; this is 8.2 right now; gvim82.exe is a corresponding installer for Windows. This offers the best compromise between stability and latest features. In the case of Vim, expect a new release roughly every year.
You'll also find development builds (something like 8.2.0740); these usually function as well and have the very latest features under development, but often are less stable. I would use these only if you really need a leading-edge feature, or want to report a bug. You should then probably update very frequently, and from there it's only a small step to actually cloning the repository and building everything on your own!
I run an open source project that normally distributes our code in a universal zip format. In addition to the core software, we also have several community developed add-ons for the software.
Rather that getting the user to download all of the options from disparate locations and websites, I'd like to provide a small footprint installer that would
Download and install java as needed. If the user is on 64bit OS, it would need to download both 32 and 64 bit.
Download and unpack the core software zip file
Allow the user to choose the latest stable version or the development version (two different websites)
Choose the additional software options (multiple options)
Download each one individually (different websites)
Unpack/Install as necessary
Write configuration files (plain text)
Clean up directory as needed depending on the configuration options.
E.g. if I select optional software "1", delete directory "X"
I don't necessarily want to provide all of those additional software options in the core installation file (in fact, if I could just provide an installation program with a small footprint that could determine the latest versions of all the available software (probably have to screen scrape some websites, others might provide a text file with the version number in it)
Is Install4j suitable for this?
I know that I would have to write some code to do the version identification, but mostly I want a GUI with a guided path for the user to choose the options and for it to download them as needed.
Once I've written the script, I'd prefer to leave it be and not have to compile new versions all the time (if possible), excepting the instances where the URL information might change.
You can use "Download file" actions to download ZIP files from arbitrary sites and then "Install contents of ZIP file" actions to install them as needed.
As for the presentation to the user, you can use the standard installation components facility where you can order installations components into a tree which is displayed on the "Installation components" screen. You can leave all the installation components empty in your case. Another advantage is that you can specify dependencies for installation components.
In the "Installation screen", I would add action groups that contain pairs of "Download file"/"Install contents of ZIP file" actions (and whatever other action are required for each component). The condition expression of each action group should be set to
context.getInstallationComponentById("123").isSelected()
where "123" is the ID of the corresponding installation component.
As for 64-bit/32-bit: On Windows, I would propose to only create an installer for 32-bit with a bundled 32-bit JRE. This works just as well on a 64-bit JRE. If necessary, a separate 64-bit media file has to be created. The bundled JRE can be downloaded on demand.
On Linux I would not really recommend to bundle a JRE. If necessary, provide two separate media files for 32-bit Linux and 64-bit Linux.
As for the "guided path for the user", you can create custom screens in install4j.
Okay, I am trying to write an installer that installs multiple programs. The installer needs to be able to either get the files from a web server, or be able to package the files into a single installer file.
The end result I am looking for is a user hits a webpage, they can click a link to download a single installer file and the installer goes ahead and installs each of the programs. Quiet installations would be preferable but not absolutely necessary. I am trying to make this as user friendly and idiot proof as possible.
Grabbing the installers for each program from a web server would be preferable so it always grabs the latest version and I will not have to tweak the installer script each time the programs are updated.
I have looked into NSIS and MSI, and neither seem to be able to do what I need. I have entertained the idea of using Java Web Start to run a Java program that can install everything, but I am not sure the plausibility of that. If that is possible, then the user would not even need to run a file the Java Web Start would just take care of everything.
Perhaps Ninite will help.
If not, there are two possible solutions:
You can try using a MSI wrapper which installs the applications as prerequisites or through custom actions. It's dirty and complicated, but MSI is a standard.
You can write your own application which handles the installers. This is most likely the best approach.
When you install your product locally, all the needed files are stored in the machine.
When you set the features to Advertise, files will be installed locally when the user launches the application.
What happens then when yo set the features to "run-from-source"? I Googled it and was only able to find this: http://msdn.microsoft.com/en-us/library/aa367538%28v=vs.85%29.aspx
Thanks!
This is a rarely used feature of Windows Installer and I don't normally reccomend using it. It was invented back in a day when hard drives were small and the thought was you 'advertised' ( pretend install aka install source ) a feature and that when the user clicks the shortcut it would go to the source and finish the installation of the feature ( aka install local )
It just adds a lot of complexity to your servicing model. It's not worth it IMO.
When placing all installation files next to the MSI (similar to advertised installation), you can install features from source. This means that all files in these features will be used from the MSI location (they are not copied in the target folders during install).
Running from source can be used when the installer remains permanently on the target machine. So the application can use the installer directly instead of using installed files.
I have several scripts that I supply to users as tools for their engineering projects. These scripts contain a lot of duplicated code. I want to extract this code and maintain it in a set of modules. However, in order for this to work, the users would have to install these modules. I don't want to have to tell my users to "make install", etc., as I'm sure none of them would have the patience for that.
I understand that one option is to package everything together with PAR, but ideally the user would be able to open up && edit these scripts if they need to, just like they can now. They also need to be able to move them to whatever directory they want, and I don't want them to have to move a bunch of library files as well.
Is it possible to make a double-click file that installs some bundled Perl modules?
I distribute my script as modules, and then use the normal CPAN toolchain to install them. See my articles Scripts as Modules and Automating Script Distributions with scriptdist. Once you have them in a conventional module distribution, you can install them from their current directory with cpan:
% cpan . # install from distribution in the current directory
Depending on how complex your situation is, you might want to create a DPAN, which is a private version of CPAN that your CPAN tools can draw from. You put all of your private modules there, point your CPAN tools at it, and everything happens as it does with a real CPAN mirror. You never have to share your work though.
yeah package with either PAR or Shipwright (not sure about binaries). Also use scandeps.pl along the way.
If the users are using systems with a packaging system (dpkg, cygwin, etc.), consider using that.
If you don't mind spending some green, one of the better bet is Perl Dev Kit from Activestate.
From their own description of the product,
Develop and deploy your Perl programs
to anyone on any platform with
PerlApp's new cross-platform
wrapping.
Deliver code as
executables or as Windows Services,
ActiveX components, .NET assemblies
or in the System Tray.
Easily create
MSI files using Perl code.
You may also consider using sparrow - scripts distribution system. Sparrow plays nice with Perl as it writen on it. It supports CPAN modules dependencies via carton tool.
PS Disclaimer - I am the tool author