Teleconference 8/12/11

Attending: Ted Ralphs, Bill Hart, John Siirola, Dave Hart

Agenda: Discuss initial ideas with the Sandia folks, who have experience with installers on Windows.

InstallJammer development dicontinued


The Sandia folks have had a lot of experience with installers, especially on the Windows platform. They first summarized what was important in their efforts. A key for them was using the registry to keep track of installed versions, to be able to query and change the user's path, and to ensure smooth uninstallation. They moved eventually to the Microsoft's newer MSI software installation system mainly because it supports silent installs for dependent packages. They decided to bundle all binaries, whenever possible, in the installer, since this was less painful than the problems some users would hhave with firewalls and other connection issues if the installer tried to download something on its own. Having a robust uninstall is important if the installer my fail and makes a lot of changes to the system (the registry, for example). It's nice if the installer supports installation of desktop icons, submenus on the programs menu, etc. If the installer will be downloading and installing any third party software, it's crucial that it have a silent install mode so as not to confuse users. A very important feature is the ability to log what happened during the installation. This is mainly for debugging when installations fail.

As far as I can see, InstallJammer does everything that was identified as important, but it is worthwhile to look into this and make sure before going much further.

There was a detailed discussion of what to do about versioning and conflicts between versions. In some sense, this is not much of an issue with static libraries on Windows, since they are linked at compile time and the user must explicitly determine what library to link to anyway. For binaries, since they are not calling any .dll's, there is no issue there. With that said, several ideas for dealing with versioning were:

  • Only install binaries and not libraries. Just assume that developers know enough to get the libraries and build/install them on their own.
  • Since all versions associated with a particular stable branch of CoinAll are compatible, it would be possible to just install any libraries or binaries in a subdirectory according to the CoinAll version number they are associated with, i.e. COIN1.4/, COIN1.5, COIN1.6, etc. There would only be an issue with setting paths. I think the logical thing would be to set the path so that if there are multiple copies of a binary installed, the latest one would be chosen. With this plan, we would have one series of installers for each CoinAll version. Alternatively, we could simply have one installer for each CoinAll version. This would be less confusing for users, but the installers would be large if they included all libraries and binaries for a given platform.
  • Another option would be to try to use pkg-config somehow. Pkg-config makes it possible to query what version of software are installed through configuration files that are produced at compile time. Actually, the reason we decided to support pkg-config was because it does roughly the pkg-config files do roughly the same job as RPMs, but pkg-config is available on Linux, Mac, and Windows, which is a big advantage. In fact, I believe it's installed by default in Linux and OS X. Unfortunately, pkg-config still does not have a Windows installer. Not only that, but it depends on some other libraries that also do not have installers. You can get everything needed at the GTK+ project download page and all that is required is to unpack and zip file somewhere and set your paths. Alternatively, pkg-config does come with CYGWIN as well. An option if we want to use pkg-config would be to do our own installer and require users to first install that before installing COIN.

Another meeting will be scheduled for next week.

Initial strawman proposal for creating installers for COIN projects

There has been a lot of interest recently in putting some effort into creating installers for COIN projects. and with the recent improvements to the build tools completed, now is a good time to pursue this. At present, the proposal on the table is to use InstallJammer as the platform for generating the installers. There are a number of reasons for this.

  • It is open source and well supported.
  • We have several people with experience using it who are willing to contribute.
  • The format for the installer creation files is easy to parse, which means we can automatically generate the installers (important).

A few questions need to be answered to get things started and these are listed below with some tentative answers based on preliminary discussions. Hopefully, this list will move us forward

  1. What installers are needed? Should we have separate installers for each project? Or one installer that offers the option to install any one of a number of different COIN projects? I was leaning towards the latter, since it takes care of the problem of ending up with multiple copies of a single library (like CoinUtils) installed.

Considering the scenario of having a distribution which can install more than one COIN-OR component at once (this would be great for laboratories or anyone who is exploring coin-or resources), I (Haroldo) was thinking in the following directory structure (some example entries installation included):

                 cbc symphony ...
                 libCgl.a libClp.a libSym.a libCbc.a  ...
                     CoinAlloc.hpp OsiSolverInterface.hpp ... 

In windows the installation prefix could be "Program Files" and in Linux I think that /opt is a good place to install software which does not comes in the distribution by default.

  1. What compilers do we support? On Windows, do we offer separate installers for MSVC++ and CYGWIN/MinGW? Or one installer that offers to install binaries for both/either?

I think that we can include all in the same installer. Some users may prefer to decide latter which compiler they will use.

SV: I don't see how the binaries/libraries generated via the MSVS project files and under cygwin/mingw with MS compiler differ. There may be a small difference in the configuration header files. However, I don't know how the MSVS projects install the binaries, libs, and headers actually.
The tuple (OS, cputype(32 or 64 bits), compiler) may define the platform for which a specific set of binaries/libraries/headers is meant, see also here.

  1. What configurations do we support? I suppose we just support the basic ones. We have to worry a bit about distributing any GPL'd software along with COIN (technically, we cannot do this), so that means not linking in Glpk, for instance.

Yes, unfortunately GLPK has this license which is more restrictive than the Eclipse Public License...or, we could include and depending of the selected components show the License along with a "I Accept" button. We could contact Andrew to see if this is enough (I think that we also have to always distribute sources for GPL software)

  1. What options do we offer at install time? Do we offer an option for developers versus people who want to just have executables, i.e., do we ask whether to install individual libraries and headers or just executables? At the moment, I do have this option with my SYMPHONY installer (at least on Windows), but we could also just install the supporting libraries and headers without asking.

We could have a "Custom Install" where this option would be available. In default installation I think that the whole package (programs and development files) should be installed. Disk space is not a concern these days.

SV: I would suggest to just leave out Glpk.

  1. Do we include all of the binaries in the installer itself, i.e., do we force the user to download all the available projects, even though they may not all get installed (assuming a monolithic installer for all projects). Or should the installer itself be minimal and go and get the binaries requested by the user after prompting for which projects to install? I am leaning towards the former since you otherwise have trouble with firewalls and off-line installs. The advantage of the latter is a smaller installer download initially.

I think that it is more practical to download a self contained installer so that people can put it in a usb stick/network mapped disk and install in many machines.

  1. How do we support upgrades? We have put a lot of thought into allowing smooth upgrades so we can do more point releases. It would be nice to have installers that check for previous versions and do smooth upgrades.

Yes, I think that InstallJammer has a nice support for checking installed versions of packages.

  1. Can we support generating of .deb and .rpm with InstallJammer? We have already put a lot of thought into how to construct the build system to better support installation by package managers on Linux.

InstallJammer has an option to generate "silent installs", so that you pass options to the installer and it installs everything without human intervention.To generate binaries capable of running in different linux distributions (fedora, ubuntu...) we can use static binaries (so that distribution specific libraries are not needed).

  1. Can we generate the Install Jammer project files automatically? If we can do this, it certainly makes it more viable to have installers for individual projects if we want. We have scripts for doing the builds and creating the binary distributions. If we could somehow also generate the installer automatically, that would be great!

Yes ! I have already checked that and the format is not hard to understand. We could automate the generation of installers for all coin projects. We could group files of different projects in predefined categories (binaries, development... documentation) and automatically generate a COIN installer for this every. Every COIN installer would have some common parts (e.g.: show the Eclipse Public License).

Last modified 10 years ago Last modified on Aug 23, 2011 6:33:15 PM