[Top][All Lists]

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

Re: Symlinks from Tools to Applications

From: Richard Frith-Macdonald
Subject: Re: Symlinks from Tools to Applications
Date: Mon, 19 Feb 2007 16:14:12 +0000

On 19 Feb 2007, at 11:45, Christopher Armstrong wrote:


Richard Frith-Macdonald wrote:
That being said, IMO we *need* gnustep-make to be able to build windows packages for applications. Let's say gnustep-make supports automatic creation of WiX packages for instance ...
You do 'make wix' or something like that, and it builds your package.
The user double clicks the package to get the installer to install it, and as part of the installation process the installer asks the user if it should create a link to the app from the desktop or somewhere else. Then the user just has to double click the app to run it.
I've been investigating the use of WiX for creating installable packages. Unfortunately, it is not really suited for the kinds of things we need to be able to do in an installer. I'll try to explain the reason why, but I believe it boils down to creating a logistical nightmare if we change directory structures or the files included with a program. It logically separates groups of files into Components, but it will not let these "Components" be split over a file hierarchy but rather only within the same directory. This doesn't let us, for example, split an application wrapper into a number of interface files and frameworks, as each directory within the framework needs to be a separate component, and it sort of makes the assumption that files are always to be installed in the same location (this is not really flexible enough). If you could imagine trying to use it with something that contains Unix paths such as MinGW, there is no logical way to separate along such lines as gcc-core, gcc-objc, gcc-g++ etc as their files are split across many directories.

I hadn't spotted that problem.

It also associates GUIDs with the components, which means that a component is not likely to "change" at all. It was really designed for .NET applications which only consist of a bunch of local DLL's and an executable, not the complex app wrappers we have. If a component has its files changed, we need to reuse the same GUID, which is near impossible to handle in makefiles. The only advantage it really has is component tracking for removal and upgrading, but its idea of a component is too out of step with GNUstep such that it is too much of a headache.

I had spotted that one, but was hoping that a more in depth study would show up a way to work around it.

Another issue is that it doesn't support automated download of dependencies as far as I can see, and the declarative nature of the package files makes it hard to see how adding a dependency download mechanism could be done cleanly.

The WiX idea of tagging everything independently to allow upgrade of each bit separately is pretty attractive, but I think a better solution for GNUstep is to have smaller packages able to download dependencies automatically. The first format is simpler for distribution on cd-rom, but I don't think that's what we are aiming at.

NullSoft's installer (NSIS) seems to be a better option, as we can just hand it a directory and tell it to copy it to a location, then continue to execute some custom commands. It is scriptable as opposed to WiX, which is declarative (XML files). MinGW use it for their installer, so we can use this as a base to build a "Dev environment" installer. Unfortunately the script consists of macros and a stack based language, but this shouldn't be too much of an issue as it at least permits some logic handling and functions. It has been used in complex projects such as Firefox and is in fact portable across x86 to FreeBSD and Linux (not that we'd necessarily do this). I can't seem to find other solutions that are free and open source (anyone know any?)

I must admit, apart from a cursory scan of search results from google, I've only looked at WiX ... mostly because most of the references I saw seemed to regard it as 'approved' or 'standard' pacakging tool. It does sound like NSIS would be a better option though.

I think it should be fairly simple to get the makefile package to generate installer scripts for either NSIS or WiX.

Good. I thought so in principle, but there is always some trouble when you get to the detail ... nothing we can't solve though I'm sure.

reply via email to

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