[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: Mon, 19 Feb 2007 22:45:50 +1100
User-agent: Thunderbird (Windows/20061207)


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.

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.

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?)

Adding support for building packages for different systems to gnustep-make is too big a job to ask Nicola to undertake on his own (especial;y windows packages when, afaik, he doesn't even own a windows machine), but it's probably something that, with his advice, could be largely separate and undertaken by different people. Maybe Nicola won't agree that package building should be part of gnustep-make, but it seems a natural place to put it to me (though add-ons to do it may be possible) We already have RPM package building support (under-used in my opinion) so I think the two most important additions are:
1. windows package building
2. source package building ... something that automatically tracks dependencies, downloads all the source code needed, builds it all, and installs it all. I think gentoo does this, and perhaps we could rip off their system. This would give us something akin to a 'universal' package builder (especially if we could make our packages such that the builder could bootstrap itsself, if necessary, as the first part of the process). Maybe this is too big a task even re-using gentoo code ... just an idea. Anyway, I think it would be good if 'make install' would set this registry key up, and any package we create would also set the key up.
I think it should be fairly simple to get the makefile package to generate installer scripts for either NSIS or WiX.


reply via email to

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