Installers

While wxWidgets provides a platform independent solution to just about every aspect of typical applications, there isn't currently one simple solution for distributing cross-platform installers (maybe someday we can hope to see an application that can build everything needed). This guide aims to provide simple instructions for distributing your wxWidgets application on each platform.

Windows

WiX

Windows Installer XML (WiX) toolset The Windows Installer XML (WiX) is a toolset that builds Windows installation packages from XML source code. The toolset supports a command line environment that developers may integrate into their build processes to build MSI and MSM setup packages. It has a project plugin for Visual Studio .NET 2005 as well, but this does not work with the express editions of Visual Studio .NET 2005.

Inno Setup

Inno Setup by Jordan Russell is a free installer. You can either write the setup yourself or use a script generator listed here.

Ghost Installer

A skinnable installer that supports multilanguage install packages, and has plug-ins to extend its functionality. It is available for free (with a Ethalone splash), and has commercial licenses available from $299 to $699.

Official website: http://www.ethalone.com/products.php

NSIS (Nullsoft Scriptable Install System)

NSIS is a quick and easy installer, particularly for people comfortable with editing text configuration files (like Makefiles or RPM .spec files).

It has several sample configurations, which can be readily modified for your project, as well a web page to get you started with a custom configuration file for your project. There are also 3rd party configuration "builders" linked to from the site, and many tools and add-ons to make your installs more powerful.

NSIS includes some scripts to generate "Installation Wizard"-style installers extremely easily, which is called MUI. Look at the MUI directory after installation for docs and examples.

Self-Extractors

Many archivers offer the ability to create customizable SFX-executables. For example, WinRAR allows you to create a basic installer with pre- and post-installation script execution. The GUI can be customized (resource editing also possible) and scripts are only limited to batch file functionality (but you can always write and execute your own small patcher if you need, right?).

Mac OS

Most Mac applications do not actually come with installers. Instead, they are simply distributed as archived folders that are automatically uncompressed by the web browser upon download, usually to the user's desktop. Most Mac programs are happy running from any location on the user's hard drive, and Mac users generally love the freedom of being able to put applications wherever they want.

On Mac OS X, the preferred file format is a disk image (.dmg) when it doesn't require an installer. To create a disk image, just use the Disk Copy program that comes with Mac OS X (in the Utilities folder), from there you can select "Create Disk Image from Folder" in the menu.

One downside of disk images is that they are not quite as intuitive as archives, because they turn into mounted volumes, rather than ordinary folders. Some users don't realize that they need to copy the contents of the volume to their hard drive. Apple has provided a solution for Internet downloads, called "Internet-enabled" disk images. These disk images will automatically turn themselves into a file or folder the first time you download them or double-click on them.

The other option, .zip files, are easily created from the Finder; just select your folder and use the menu option File > Create Archive of... (or use the contextual menu, that is, Control-click or right-click on the folder). They result in actual folders which may be easier for some users to grasp. Note that you may encounter problems with resource forks or other unintended consequences if your .zip archive is expanded on an OS earlier than 10.4.

Sometimes you do need to use a real installer. If your program must install system extensions or otherwise make modifications that require administrator privileges (only applies to Mac OS X), you will need to use an installer.

For Mac OS X, Apple has PackageMaker available as part of their Developer Tools (available for free at their Developer website). In addition, there is

Linux

The Problem

The process of packaging and distributing your application on Linux can be significantly different with every distribution.

Unlike Windows, where most programs typically link only against the DLL shipped by Microsoft with the OS or provide the additional DLL in the installation process, Linux makes a much more intensive use of shared libraries. That's why typically even big programs on Linux are a lot smaller than Windows ones: they reuse a lot of code in form of shared libraries.

This approach also has the disadvantage that any little ABI break (ABI is the Application Binary Interface of a library) between the version of the libraries used at compile-time and the version available on the user's system will make it impossible for the dynamic linker to start your program.

Unfortunately many Linux distribution ship with different ABIs even for some of the most widely used libraries. This is known as the "DLL hell" and is the reason why the ELF you (as developer) compile on your favourite Linux distribution likely won't run on other distributions (or even in later versions of that same distribution).

This often means developers are required to create separate application packages for each distribution (as well as different versions of the same distribution). Outlined below are two of the more common approaches to solving this problem efficiently.

Solution #1: DEB and RPM

Usually most people which still want to provide to the user precompiled binaries adopt the simple solution of providing binary packages only for the most used distributions (Debian, Ubuntu, Mandriva, SuSE, RedHat, etc, etc - see http://distrowatch.com/ for more updated statistics).

To create an RPM look at RPM creation HOWTO; it is a widely used package format but remember that the RPM you create e.g. on Mandriva won't probably run on other RPM-based distributions.

To create a DEB (debian package) look at DEB creation HOWTO. Same warning for RPM: a DEB built on Debian won't probably run on other DEB-based distributions (e.g. Ubuntu).

Note that do exist also other tools like e.g. Alien which can convert from RPM to DEB packages or viceversa.

You may want to look to the page Linking_With_Gtk_And_Running_On_Any_Linux for more info about creation of a more compatible package. Consider however that wxWidgets is now packaged in most of the Linux distributions and that all wxWidgets releases with the same MAJOR and MINOR number (e.g. 2.6.1 and 2.6.3) are binary compatible (i.e. have a compatible ABI); this means that linking wxWidgets statically in your binary may not be the best choice. Not only because your binary will be bigger: dynamic linking means that if the user's distribution ships a new (ABI compatible) version of wxWidgets, your program automatically will start to use it (and maybe take advantage of the bugfixes of the new release).

Solution #2: Autopackage

A different solution is represented by AutoPackage. This project aims to provide a distribution-neutral packaging system! This means that just as you create only one installer of your app for all Windows versions, you can create a single package for your app for all (well, in theory) Linux distributions!

Since version 2.7.2 wxWidgets officially supports Autopackage for wxGTK port. If you download the 2.7.2 (or later) releases of wxGTK you'll find inside the distrib/autopackage/sample folder the minimal wxWidgets sample and the APSPEC file required to create an autopackage for it. In that folder you'll find also a README which explains how to build the sample and its autopackage.

In any case, before you can start creating autopackages for your wxWidgets-based applications, you should look first at Autopackage docs and then at the Autopackage for the minimal wxWidgets sample.

Solaris

Post the integration of wxWidgets (wxGTK) into OpenSolaris, you can get the packages directly from the OpenSolaris repository. Click here for more details.

Also, There is a (most likely outdated) guide for building Solaris packages here. Feel free to contribute some updated documentation here.