[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Symlinks from Tools to Applications

From: Christopher Armstrong
Subject: Re: Symlinks from Tools to Applications
Date: Tue, 20 Feb 2007 23:41:11 +1100
User-agent: Thunderbird (Windows/20061207)


NSIS is really nothing more than a stack based programming language. It just happens to have a rich set of modules for assembling an installer and a very good supporting community. Package "Management" can certainly be contained considering a number of issues:

1. Mingw, MSYS and the GNU libraries don't change often enough to break binary compatibility between versions very easily. It is reasonable to treat any version of these as "stable" and good enough for long-term use without upgrading all the time.

2. One of the key issues is binary compatibility between applications and tools, and the gnustep libraries. This does seem to change between versions, so we will need some versioning information to be stored with "packages" for download, including a minimum base/gui combination for an application binary. Frameworks would seem to be a partial answer to this issue, but only if applications or tools are linked against the right version of a framework and that framework version is correctly loaded when an application or tool is loaded.

Another possible solution is to allow dll versions to be embedded in the name of the dll on Windows (currently we have gnustep-base.dll and gnustep-gui.dll). We could at least have only a major number embedded in the name of these (such as gnustep-gui1.dll for 1.0 and gnustep-gui2.dll for unstable versions, etc).

Windows XP also allows the embedding of "manifest" files, which allow an application to specify the version of libraries that it is linked against, such that Windows tries to load up the correct version of a library when faced with an incorrect version. I'm not sure how this works exactly, but could be a useful solution.

The most inefficient solution in this case may end up being the simplest and least hassle; we simply just uninstall all application binaries when the GNUstep libraries change binary compatibility. For the time being though, I think this issue is best left unsolved as we just want an installer first that knows when it can upgrade software. We should just tell the user that if they are upgrading GNUstep they should upgrade their programs.

On that note, if a class's binary compatibility changes, is there a programmatic way for a program to find out that its loaded a library with an incompatible class version and inform the user that the program needs to be recompiled or upgraded? I know Objective-C classes support versions, but its not clear how this works. Also, if applications don't access the instance variables of a class, this would certainly improve their binary compatibility as they wouldn't care about the internal layout of the class?

3. Most of these tools we would be trying to provide as a basis for developers to create and bundle applications for Windows as just one target platform, albeit an important one. To a certain extent, packages could just be limited to installing the GNUstep libraries.

In all, I think we will end up having to write much of this ourselves, as no real Windows solutions exist. As attractive as WiX is for this issue, IMHO it will end up introducing additional problems.


Richard Frith-Macdonald wrote:

On 20 Feb 2007, at 02:38, Christopher Armstrong wrote:
I was thinking an all-in-one installer, that let the user select between a "user" and "developer" installation. The "user" one would contain 1 & 2 (possibly 3), the "developer" containing all of them. The MinGW installer again has a good idea on doing this; we store an .ini file on our web site and the installer downloads this to get the locations and names of the packages needed to be extracted on a user's HD. To make things more flexible, this file should store a archive name and version so that we can work out what needs to be upgraded in the event the user already has parts of GNUstep already installed. How to handle upgrades is a little bit unclear, as we should remove old files instead of extracting over the top (perhaps we can store a list of files that was installed with a package?).

That sounds pretty much what I was thinking ... a small installer package which could either
1. download and install the runtime environment for a user or
2. download and install the full development environment
and would be capable of checking package versions and upgrading (by uninstalling the old version and installing a new one)

Supplemented by a makefile (to be installed like the existing rpm make file) to automate creation of a package for a library/framework/tool or application. Each if these packages would know how to download and install the runtime environment and/or any other packages it needs.

Basically, my ideal is a package management system rather than a simple installer ... and perhaps that's just too ambitious. However, I wonder if there is already a tool which could be used to manage the dependency/version tracking part of this. It looks like NSIS is flexible/powerful enough to let us add that sort of logic, but it's not built in, and it would be nice if we could find an existing system that would integrate well with NSIS, to handle that. The only thing I see on the net is winpackman ... and that doesn't look mature/stable :-(

reply via email to

[Prev in Thread] Current Thread [Next in Thread]